靈活軟體開發11個原則

裡面提到的部分原則，是我現在碰到了問題的、或者考慮到了的。更多的，還需要學 習、實踐。

靈活軟體開發-面向對象設計的11原則

"你不必嚴格遵守這些原則,違背它們也不會被處以宗教刑罰.

但你應當把這些原則看成警鈴,若違背了其中的一條,那麼警鈴就會響起."

author:chinayaosir QQ:44633197

1.SRP單一職責原則[适用于類功能]

(就一個類而言,應該僅有一個引起它變化的原因.)

詳細說明:

如果一個類承擔的職責過多,就等于把這些職責耦合在一起.

一個職責的變化可能會削弱或者抑制這個類完成其它職責的能力.

這種耦合會導緻脆弱的設計,當變化發生時,設計會遭受到意想不到的破壞.

結論:

它是所有類設計原則最簡單的,也是最難正确使用的.

我們會自然的把職責結合在一起,軟體設計真正要做的内容就是發現職責并把那些職責互相分離.

2.OCP開放-封閉原則[适用于類抽象]

(軟體實體(類,子產品,函數...)應該是可以擴充的,但是不可以修改.)

OCP=對于擴充是開放的,對于修改是封閉的.

如果程式中的一處改動就會産生連鎖反應,導緻一系列相關子產品的改動,那麼設計就有臭味.

OCP建議我們如果要對系統進行重構,就隻需要添加新的代碼,而不必改動已經正常運作的代碼.

在許多方面,OCP都是面向對象設計的核心.

尊循它可以帶來巨大的好處(程式的靈活性,可重用性,可維護性).

在代碼中肆意使用OCP也不是一個好主意.

正确的做法是：開發人員僅僅對程式中呈現頻繁變化的部分做出抽象！拒絕不成熟的抽象和抽象本身一樣重要!

3.LSP Liskov替換原則[适用于類層次]

(子類型必須能夠替換掉它們的基類型.)

詳細說明: 

Barbara Liskov在1988年說道:

Liskov替換性質:若對每個類型S的對象O1,都存在一個類型T的對象O2,

在所有針對類型T編寫的程式P中,用O1代換O2後,程式P行為功能不變,則類型S是類型T的子對象.

LSP是使用OCP開放-封閉原則成為可能的主要原則之一,

正是子類型的可替換性才能用基類類型(基類引用或者指針)的子產品在無需修改的情況下就可以擴充.

這種可替換性是開發人員可以隐式依賴的東西.

是以,如果沒有顯示的強制基類類型的契約,那麼代碼就必須良好并明顯的表達出這一點.

術語"IS-A"不能作為子類型的定義,

子類型的正确定義是"可替換性","可替換性"可以通過顯式或者隐式的(動态綁定必須用基類類型)契約.

4.DIP依賴倒置原則[适用于類層次]

(抽象不應該依賴細節.細節應該依賴抽象.)

a.高層子產品不應該依賴于低層子產品,二者都應該依賴抽象(使用接口或者虛類來連接配接).

b.抽象不應該依賴于細節,細節應該依賴于抽象.

結論: 

使用傳統的過程化程式設計方法所建立出來的依賴關系結構和政策是依賴于細節.

DIP使得細節和政策都依賴于抽象,并且常常為客戶定制服務接口.

事實上,這種依賴關系的倒置是好的面向對象的程式設計的标記.

DIP正确應用對于可重用架構是必須的,對于建構在變化面前富有彈性的代碼也是非常重要的.

由于抽象和細節被DIP彼此隔離,是以代碼也非常容易維護.

5.ISP接口隔離原則[适用于類的接口]

不應該強迫客戶程式依賴于它們不用的方法.

接口屬于客戶,不屬于它所在的類層次結構.

分離客戶就是分離接口.分離接口有2種方法:委托和多重繼承

接口隔離原則是用來處理胖接口所具有的缺點.

如果類接口不是内聚的,就表示該類的接口是胖的,需要減肥.

減肥的原則是接口分成多組方法,每一組方法都服務于一組不同的客戶程式!

客戶程式面對的就是多個具有内聚接口的抽象基類.

胖類會導緻它們的客戶程式之間産生不正常的有害的耦合關系.

當客戶程式要求胖類進行一個改動時,會影響到所有其它戶程式.

是以,程式應該僅僅依賴于它們實際調用的方法.

通過把胖類的接口分解為多個特定的客戶程式的接口,可以實作這個目标.

每個特定于客戶程式的接口僅僅聲明它自己調用的函數.

解除了類的客戶程式之間依賴關系,使它們互不依賴.

6.REP重用釋出等價原則[适用于包]

(重用的粒度就是釋出的粒度)

當你重用别人一個類庫時,你的期望是什麼？

當然是好的文檔,可以工作的代碼,規格清晰的接口!

你希望作者會一直維護類庫代碼,當作者都把類庫的接口和功能進行任何改變時,你希望得到通知.

代碼的作者把它們的軟體組織到一個包中(dll,jar,...),是以我們重用的粒度就是包的釋出粒度.

一個包的重用粒度和和釋出粒度一樣大,由于重用性是基于包的,是以可重用的包必須包含可重用的類.

7.CCP共同封閉原則[适用于包]

(包中的所有類對于同一類性質的變化應該是共同封閉的.

一個變化若對一個包産生影響,則将對該包中的所有類産生影響,而對于其它包不造成任何影響.)

這是SRP單一職責原則對包的重新規定.這規定了一個包不應該包含多個引用包變化的原因.

在大多數應用中,可維護性超過可重用性.

代碼更改:如果代碼要更改,原意更改都集中在一個包中,而不是分布于多個包中.

代碼釋出:我們也隻釋出更改中的包!

結論:    

CCP鼓勵我們把可以由于同樣的原因而更改的所有類共同聚集在同一個包中.

8.CRP共同重用原則[适用于包]

(一個包中的所有類應該是共同重用的.

如果重用了包中的一個類,那麼就要重用包中的所有類.)

一個包中的所有類應該是共同重用的.

如果重用了包中的一個類,那麼就要重用包中的所有類.

這個原則可以幫助我們決定哪些類應該放進同一個包中.

9.ADP無環依賴原則[适用于包]

(在包的依賴關系圖中不允許存在環.)

如果開發環境中有許多開發人員都在更改相同的源代碼檔案集合的情況,

因為有人比你走的晚,且改了你所依賴一些東西(類或者方法),第二天來上班,

你昨天完成的功能,今天不能正常工作,那麼就會發生"晨後綜合症"!

針對此問題有兩個解決方案:"每周建構"和"消除依賴環" 

每周建構:應用于中等規模的項目中,它的工作方式為:每周1-4,開發人員各自工作在私人的代碼空間,周5-6聯合調試！

消除依賴環:通過把開發環境劃分成可釋出的包,可以解決依賴環.

解決包之間的依賴環有兩個主要方法：

1.使用依賴倒置原則,在類和依賴類之前添加一個依賴的接口或者抽象類,解除依賴環.

2.添加新類,把類和依賴類之間的依賴移到一個新的類,解除依賴環.

10.SDP穩定依賴原則[适用于包]

(朝着穩定的方向進行依賴.)

設計不是完全固定的,要使設計可維護,某種程式的易變性是必要的.

使用這個原則,我們可以建立對某些變化類型敏感的包.

其它的包不要依賴這個要變的包.

軟體包就可以分為穩定包和可變包!

如何識别穩定包和可變包？如果許多其它的包都依賴此包,那麼它就是穩定包,否則就是可變包！

把包放在不同的位置,它的穩定性是不同的.

如何計算一個包的不穩定性？(輸入耦合度Ca,輸出耦合度Ce)

不穩定值=Ce/(Ca+ce),此值越低越穩定!

把可變包不穩定值降低的方法是:為它加上一個抽象外衣(interface/抽象類),其它包調用抽象外衣!

可變包為抽象外衣的實作!

11.SAP穩定抽象原則[适用于包]

(包的抽象程式應該和其它穩定程式一緻.)

詳細說明:   

此原則把包的穩定性和抽象性聯系到一起.

一個穩定的包應該是抽象的,這樣它的穩定性就不會使其無法擴充;

一個不穩定的包應該具體的, 這樣它的不穩定性使代碼易于修改.

它指出一個包有時候應該達到部分是可抽象的,部分是不穩定的原則