讀書筆記9:物件導向設計原則

來源:互聯網
上載者:User

單一職責原則

就一個類而言,應該僅有一個引起它變化的原因。職責即為“變化的原因”。

開放封閉原則

軟體實體(類、模組、函數等)應該是可以擴充的,但是不可修改。對於擴充是開放的,對於更改是封閉的。關鍵是抽象,將一個功能的通用部分和實現細節部分清晰的分離開來。

理氏替換原則

子類型必須能替換掉他們的基本類型。

依賴倒置原則

抽象不應該依賴於細節。細節應該依賴於抽象。程式中所有的依賴關係都應該終止於抽象類別和介面。針對介面而非實現編程。任何變數都不應該持有一個指向具體類的指標或引用。任何類都不應該從具體類派生。任何方法都不應該覆寫他的任何基類中的已經實現了的方法。

迪米特法則

如果兩個類不必彼此通訊,那麼這兩個類就不應該發生直接的相互作用。如果其中一個類需要調用另一個類的某個方法,可以通過第三者轉寄這個調用。其本意是,設計中要注意松耦合。

介面隔離原則

不應該強迫客戶依賴於他們不用的方法。介面屬於客戶,不屬於他所在的類階層。多個面向特定使用者的介面勝於一個通用介面。

重用發布等價原則

重用的粒度就是發布的粒度。

共同重用原則

一個包中的所有類應該是共同重用的。如果重用了包中的一個類,那麼就要重用包中的所有類。相互之間沒有緊密聯絡的類不應該在同一個包中。

共同封閉原則

包中的所有類對於同一類性質的變化應該是共同封閉的。一個變化若對一個包影響,則將對包中的所有類產生影響,而對其他的包不造成任何影響。

無依賴原則

在包的依賴關係中不允許存在環。細節不應該被依賴。

穩定依賴原則

朝著穩定的方向進行依賴。應該把封裝系統高層設計的軟體(比如抽象類別)放進穩定的包中,不穩定的包中應該只包含那些很可能會改變的軟體(比如具體類)。

穩定抽象原則

包的抽象程度應該和其他穩定程度一致。一個穩定的包應該也是抽象的,一個不穩定的包應該是抽象的。

預設抽象原則

在介面和實現介面的類之間引入一個抽象類別,這個類實現了介面的大部分操作。

介面設計原則

規劃一個介面而不是實現一個介面。

黑盒原則

多用類的彙總,少用類的繼承。

不構造具體的超類原則

避免維護具體的超類。

聯繫我們

該頁面正文內容均來源於網絡整理,並不代表阿里雲官方的觀點,該頁面所提到的產品和服務也與阿里云無關,如果該頁面內容對您造成了困擾,歡迎寫郵件給我們,收到郵件我們將在5個工作日內處理。

如果您發現本社區中有涉嫌抄襲的內容,歡迎發送郵件至: info-contact@alibabacloud.com 進行舉報並提供相關證據,工作人員會在 5 個工作天內聯絡您,一經查實,本站將立刻刪除涉嫌侵權內容。

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.