設計模式的幾大原則

單一職責原則:就一個類而言,應該僅有一個引起它變化的原因。如果一個類承擔的職責過多,就等於把這些職責耦合在一起,一個職責的變化可能會削弱或抑制這個類完成其他職責的能力。這種耦合會導致脆弱的設計,當變化發生時,設計會遭受到竟想不到的破壞。


開放-封閉原則:是說軟件實體(類、模塊、函數等等)應該可以擴展,但是不可修改。無論模塊是多麼的“封閉”,都會存在一些無法對之封閉的變化。既然不可能完全封閉,設計人員必須對於他設計的模塊應該對哪種變化封閉做出選擇。他必須先猜測出最有可能發生變化種類,然後構造抽象來隔離那些變化。

依賴倒轉原則:高層模塊不應該依賴底層模塊。兩個都應該依賴抽象;抽象不應該依賴細節,細節應該依賴抽象。(針對接口編程,不要對實現編程)

里氏代換原則:子類型必須能夠替換掉它們的父類型。一個軟件實體如果使用的是一個父類的話,那麼一定適用於其子類,而且察覺不出父類對象的區別。也就是說,在軟件裏面,把父類都替換成它的子類,程序的行爲沒有變化。只有當子類可以替換掉父類,軟件單位的功能不受到影響時,父類才能真正被複用,而子類也能夠在父類的基礎上增加新的行爲。(鳥類和企鵝的例子)

迪米特法則:如果兩個類不必彼此直接通信,那麼這兩個類就不應當發生直接的相互作用。如果其中一個類需要調用另一個類的某一個方法的話,可以通過第三者轉發這個調用。在類的結構設計上,每一個類都應該儘量降低成員的訪問權限,則其根本思想,是強調了類之間的松耦合。

合成/聚合複用原則:儘量使用合成/聚合,儘量不要使用類繼承。優先使用對象的合成/聚合將有助於你保持每個類被封裝,並被集中在單個任務上,這樣類和類繼承層次會保持較小規模,並且不太可能增長爲不可控制的龐然大物。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章