設計模式之物件導向

介面邏輯與業務邏輯分離。

使用繼承與多型提高擴充套件性和復用性。

對於專案剛開始的時候，可以不進行抽象，但是如果需求改變的時候，需要建立抽象來隔離以後可能發生的同類變化，也就是說對於程式的改動，是通過增加新**，而不是修改舊**來完成。

對於乙個類來說，應該只有乙個引起它變化的原因。職責過多會導致高度耦合。

對於擴充套件開放，對於修改封閉。

子型別必須能夠替換掉它們的父型別。這就意味著，如果乙個軟體實體裡使用的是乙個父類的話，那麼一定適用於其子類，而且替換後程式的行為不會變化。

因為子類的可替換性，所以使用父類型別的模組就可以不用修改實現同樣的功能，實現了擴充套件性。

高層模組不應該依賴於底層模組。兩者都應該依賴於抽象。

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

高層模組我理解是業務邏輯**，底層模組我理解是封裝的功能性**，也就是說業務邏輯和功能**應該依賴於抽象，兩者中間應該抽離出一層介面，降低耦合。

如果兩個類不必直接通訊，則就不應該發生直接的相互作用，需要呼叫的時候可以通過第三者**這個呼叫。

迪公尺特法則強調的前提是在類的結構設計上，每個類應當盡量降低成員的訪問許可權。盡量降低類與類之間的耦合，這樣對乙個類的修改就可以造成最小的影響，提高復用性可維護性。

盡量使用合成/聚合，盡量避免使用類繼承。

繼承關係會導致子類實現與其父類有非常緊密的依賴關係，一方面如果父類修改了，則會導致子類的行為也發生改變。另一方面如果繼承下來的實現不適合解決當前問題，則子類還需要去重寫方法或者替換為其他類，就給復用性帶來了一定的限制。

一般只有is-a的情況下才需要去繼承，如果是新增特性之類可以考慮使用composition或者aggregation。aggregation是一種比較鬆散的擁有關係，composition是一種比較嚴格的擁有關係，部分和整體生命週期一致。

優先使用composition/aggregation可以保持類的封裝性，保持類的繼承層次在較小規模內，降低耦合。

不要為**新增基於猜測的、實際不需要的功能。在需要的時候才通過重構去實現。