軟體設計中的五大原則

軟體設計中的五大原則

一、 srp the single responsibility principle 單一職責原則

乙個職責就是乙個變化的軸線

乙個類如果承擔的職責過多，就等於將這些職責耦合在一起。乙個職責的變化可能會虛弱或者抑止這個類完成其它職責的能力

–多職責將導致脆弱性的臭味

什麼是職責？職責就是變化的原因。

二、ocp， 開發封閉原則

軟體實體（類、模組、函式等）應該是可以擴充套件的，同時還可以是不必修改的，更確切的說，函式實體應該：

（1）對擴充套件是開放的

當應用的需求變化時，我們可以對模組進行擴充套件，使其具有滿足改變的新的行為——即，我們可以改變模組的功能

（2）對更改是封閉的

對模組進行擴充套件時，不必改動已有的源**或二進位制**。

世界是變化的（而且變化很快），軟體是對現實的抽象

軟體必須能夠擴充套件

如果任何修改都需要改變已經存在的**，那麼可能導致牽一發動全身現象，進而導致雪崩效應，使軟體質量顯著下降

實現ocp的關鍵是抽象。

ocp原則其實是要求我們清晰的區分策略和策略的具體實現形式。允許

擴充套件具體的實現形式（開放），同時將這種擴充套件與策略隔離開來，使

其對上層的策略透明（封閉）

三、the liskov substitution principle 可替換原則。lsp

barbara liskov對原則的陳述：

若對每個型別s的物件o1,都存在乙個型別t的物件o2，使得在所有針對t編寫的程式p中，用o1替換o2後，程式p的行為功能不變，則s是t的子型別。

違法這個職責將導致程式的脆弱性和對ocp的違反

例如：基類base，派生類derived，派生類例項d,函式f(base* p);

f(&d)        會導致錯誤    顯然d對於f是脆弱的。

如果我們試圖編寫一些測試，以保證把d傳給f時可以使f具有正確的行為。那麼這個測試違反了ocp——因為f無法對base的所有派生類都是封閉的

ood中物件之間是否存在is-a關係，應該從行為的角度來看待。

->而行為可以依賴客戶程式做出合理的假設。

四、依賴倒置原則 dip， the dependency inversion principle

高層模組不應該依賴於低層模組。二者應該依賴於抽象。

抽象不應該依賴於細節。細節應該依賴於抽象。

所謂「倒置」是相對於傳統的開發方法（例如結構化方法）中總是傾向於讓高層模組依賴於低層模組而言的軟體結構而言的。

高層包含應用程式的策略和業務模型，而低層包含更多的實現細節，平台相關細節等。高層依賴低層將導致：

難以復用。通常改變乙個軟硬體平台將導致一些具體的實現發生變化，如果高層依賴低層，這種變化將導致逐層的更改。

難以維護。低層通常是易變的。   

五、介面隔離原則 isp

不應該強迫客戶依賴於他們不用的方法

乙個類的不內聚的「胖介面」應該被分解成多組方法，每一組方法都服務於一組不同的客戶程式。

OO設計五大原則

oo的五大原則是指srp ocp lsp dip isp 1.srp single responsibility principle 單一職責原則 單一職責很容易理解，所謂單一職責，就是乙個設計元素只做一件事。srp 原則的核心含義是只能讓乙個類有且只有乙個職責，永遠不要讓乙個類存在多個改變的理由。...

設計模式五大原則

1 單一職責 不論是在設計類，介面還是方法，單一職責都會處處體現，單一職責的定義 我們把職責定義為系統變化的原因。所有在定 義類，介面，方法的時候。定義完以後再去想一想是不能多於乙個的動機去改變這個類，介面，方法。如果答案是肯定的，說明定義的類，介面，方法則多於乙個職 責。故違背單一職責，遇到這種情...

設計模式五大原則

1 單一職責原則 不論是在設計類，介面還是方法，單一職責都會處處體現，單一職責的定義 我們把職責定義為系統變化的原因。所有在定義類，介面，方法的時候。定義完以後再去想一想是不能多於乙個的動機去改變這個類，介面，方法。如果答案是肯定的，說明定義的類，介面，方法則多於乙個職 責。故違背單一職責，遇到這種...