面向對象類的設計原則小結

/************************************************************************

* 類的設計：單一職責原則

* 1、就一個類而言，應該僅有一個引起它變化的原因。

* 2、如果一個類承擔的職責過多，就等于把這些職責耦合在一起，一個

* 職責的變化可能削弱或者抑制這個類完成其他職責的能力。這種耦

* 合會導緻脆弱的設計，當變化發生時，設計會遭到意想不到的破壞。

* 3、軟體設計真正要做的許多内容，就是發現職責并把那些職責互相分離

* 4、如果你能想到多餘一個的動機去改變一個類，那麼這個類就具有多于

* 一個職責，就應該考慮類的職責分離。

************************************************************************/

/************************************************************************

* 類的設計：開放-封閉原則

* 1、軟體實體（類、子產品、函數等）應該可以擴充，但是不可修改。

* 2、此原則保證對需求的改變卻可以保持相對穩定，進而使得系統可以

* 在第一個版本以後不斷推出新的版本。

* 3、無論子產品是多麼的“封閉”，都會存在一些無法對之封閉的變化。既然

* 不可能完全封閉，設計人員必須對于他設計的子產品應該對哪種變化封

* 閉作出選擇。他必須先猜測出最有可能發生的變化種類，然後構造抽

* 象來隔離那些變化。

* 4、在我們最初編寫代碼時，假設變化不會發生。當變化發生時，我們就

* 建立抽象來隔離以後發生的同類變化。

* 5、面對需求，對程式的改動是通過增加新代碼進行的，而不是更改現有

* 的代碼。

* 6、我們希望的是在開發工作展開不久就知道可能發生的變化。查明可能

* 發生的變化所等待的時間越長，要建立正确的抽象就越困難。

* 7、開放-封閉原則是面向對象設計的核心所在。遵循這個原則可以帶來

* 面向對象技術所聲稱的巨大好處，也就是可維護、可擴充、可複用、

* 靈活性好。開發人員應該僅對程式中呈現出頻繁變化的那些部分作出

* 抽象，然而，對于應用程式中的每個部分都刻意地進行抽象同樣不是

* 一個好主意。拒絕不成熟的抽象和抽象本身一樣重要。切記！

************************************************************************/

/************************************************************************

* 類的設計：依賴倒轉原則[誰也不依賴誰]

* 1、(1) 高層子產品不應該依賴低層子產品。兩個都應該依賴抽象。

* (2) 抽象不應該依賴細節，細節應該依賴抽象。即針對接口程式設計，不

* 要對實作程式設計。

* 2、裡氏代換原則[LSP]:一個軟體實體如果使用的是一個父類的話，那麼

* 一定适用于其子類，而且它察覺不出父類對象和子類對象的差別。也

* 就是說，在軟體裡面，把父類都替換成它的子類，程式的行為無變化。

* 3、隻有當子類可以替換掉父類，軟體機關的功能不受到影響時，父類才

* 能真正被複用，而子類也能夠在父類的基礎上增加新的行為。

* 4、由于子類型的可替換性才使得使用父類型的子產品在無需修改的情況下

* 就可以擴充。

* 5、依賴倒轉其實可以說是面向對象設計的标志，用哪種語言來編寫程式

* 不重要，如果編寫時考慮的都是如何針對抽象程式設計而不是針對細節編

* 程，即程式中所有的依賴關系都是終止于抽象類或者接口，那就是面

* 向對象的設計，反之那就是過程化的設計了。

************************************************************************/

/************************************************************************

* 類的設計：迪米特法則[最少知識原則]

* 1、如果兩個類不必彼此直接通信，那麼這兩個類就不應當發生直接的相

* 互作用。如果其中一個類需要調用另一個類的某一個方法的話，可以

* 通過第三者轉發這個調用。

* 2、在類的結構設計上，每一個類都應當盡量降低成員的通路權限。

* 3、根本思想，是強調了類之間的松耦合。

* 4、類之間的耦合越弱，越有利于複用，一個處在弱耦合的類被修改，不

* 會對有關系的類造成波及。

************************************************************************/

——By 陳相禮 09/12/02