裡面提到的部分原則，是我現在碰到了問題的、或者考慮到了的。更多的，還需要學 習、實踐。
from：
敏捷軟體開發-物件導向設計的11原則
"你不必嚴格遵守這些原則,違背它們也不會被處以宗教刑罰.
但你應當把這些原則看成警鈴,若違背了其中的一條,那麼警鈴就會響起."
1.srp單一職責原則[適用於類功能]
(就乙個類而言,應該僅有乙個引起它變化的原因.)
詳細說明:
如果乙個類承擔的職責過多,就等於把這些職責耦合在一起.
乙個職責的變化可能會削弱或者抑制這個類完成其它職責的能力.
這種耦合會導致脆弱的設計,當變化發生時,設計會遭受到意想不到的破壞.
結論:它是所有類設計原則最簡單的,也是最難正確使用的.
我們會自然的把職責結合在一起,軟體設計真正要做的內容就是發現職責並把那些職責相互分離.
2.ocp開放-封閉原則[適用於類抽象]
(軟體實體(類,模組,函式...)應該是可以擴充套件的,但是不可以修改.)
詳細說明:
ocp=對於擴充套件是開放的,對於修改是封閉的.
如果程式中的一處改動就會產生連鎖反應,導致一系列相關模組的改動,那麼設計就有臭味.
ocp建議我們如果要對系統進行重構,就只需要新增新的**,而不必改動已經正常執行的**.
結論:在許多方面,ocp都是物件導向設計的核心.
尊循它可以帶來巨大的好處(程式的靈活性,可重用性,可維護性).
在**中肆意使用ocp也不是乙個好主意.
正確的做法是：開發人員僅僅對程式中呈現頻繁變化的部分做出抽象！拒絕不成熟的抽象和抽象本身一樣重要!
3.lsp liskov替換原則[適用於類層次]
(子型別必須能夠替換掉它們的基型別.)
詳細說明:
barbara liskov在2023年說道:
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),此值越低越穩定!
結論:把可變包不穩定值降低的方法是:為它加上乙個抽象外衣(inte***ce/抽象類),其它包呼叫抽象外衣!
可變包為抽象外衣的實現!
11.sap穩定抽象原則[適用於包]
(包的抽象程式應該和其它穩定程式一致.)
詳細說明:
此原則把包的穩定性和抽象性聯絡到一起.
乙個穩定的包應該是抽象的,這樣它的穩定性就不會使其無法擴充套件;
乙個不穩定的包應該具體的, 這樣它的不穩定性使**易於修改.
結論:它指出乙個包有時候應該達到部分是可抽象的,部分是不穩定的原則
敏捷軟體開發11個原則
敏捷軟體開發 物件導向設計的11原則 你不必嚴格遵守這些原則,違背它們也不會被處以宗教刑罰.但你應當把這些原則看成警鈴,若違背了其中的一條,那麼警鈴就會響起.1.srp單一職責原則 適用於類功能 就乙個類而言,應該僅有乙個引起它變化的原因.詳細說明 如果乙個類承擔的職責過多,就等於把這些職責耦合在一...
敏捷軟體開發11個原則
其它的包不要依賴這個要變的包.軟體包就可以分為穩定包和可變包 如何識別穩定包和可變包？如果許多其它的包都依賴此包,那麼它就是穩定包,否則就是可變包！把包放在不同的位置,它的穩定性是不同的.如何計算乙個包的不穩定性？輸入耦合度ca,輸出耦合度ce 不穩定值 ce ca ce 此值越低越穩定 結論 把可...
敏捷軟體開發 敏捷開發原則
編寫單元測試是一種驗證行為，更是一種設計行為。測試時乙個無價的文件。如果你想知道如何呼叫乙個函式或者建立乙個物件，會有乙個測試展示給你看。什麼是設計？不應該認為設計就是一組和 分離的uml圖。一組uml圖也許描繪了設計的一些部分，但是它不是設計。還是要 化 僵化性是指難以對軟體進行改動，即使是簡單的...