程式設計編碼理論上只要跑得起來就沒有問題了，但實際上程式是為需求服務的，需求無時無刻都有可能變更，程式也需要做出相應改變，這時如果程式設計混亂，那麼大多數時候都是沒有辦法輕微改動程式就達到需求目標的，而此時給程式大開刀也不允許，最後進入了兩難境地。所以最好一開始就依託一套優秀原則來設計程式，以下介紹面向物件設計的七個原則:

1. 單一職責原則 Single Responsibility Principle （SRP）

    一個類只負責做一件事情。

2. 開閉原則 Open-Close Principle（OCP）

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

3. 里氏代換原則 Liskov Substituition Principle（LSP）

    子類能夠替換其父類被使用。

    要求兩點：一、每一個類儘量不要重寫父類方法，如果重寫也不要影響父類原有功能；二、對比父類，子類應當擁有新功能。使得功能擴充套件時，可以在使用父類的位置，用子類替換父類，從而即不影響原有功能也新增了功能。

4. 依賴倒置原則 Dependence Inversion Principle（DIP）

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

    要求設計應該具有高度抽象性，不應一開始就考慮具體類的設計，設計者應該分析出問題的核心並依此設計解決問題的策略，用抽象的方式來解決問題，具體解決方式根據實際情況逐漸細化，以此使得問題的解決不直接依賴於具體實現。

    比如足球進球，進球是目的，達到目的的一種方式是做擡腳，踢中足球這兩個事情，是具體實現，這兩個事情是我們用踢球這個方式最後解決進球這個問題時必須做的，但進球還可以用頭把球頂進球門這種方式，解決問題的方式有多種，不同情況採用不同解決辦法，但為了從大局上描述如何解決進球這個問題，在設計時我們首先應該把擡腳，踢中足球這兩個事情或用頭頂球這個事情抽象為“做動作”這個概念，在具體解決問題時再把這個“做動作”概念具體化，最後使用具體化的辦法解決問題。

5. 介面隔離原則 Interface Segregation Principle（ISP）

    使用多個專用的小介面，而不使用一個通用的大介面。

6. 組合/聚合複用原則 Composition/Aggregation ReusePrinciple（CARP）

    類間關係儘量使用關聯關係（組合、聚合），儘量少用繼承關係。

7. 迪米特法則Law of Demeter（LoD ）

    一個物件只對另一個物件保持最少的瞭解，只與“直接朋友”通訊。

    “直接朋友”包括：當前物件；當前物件的成員物件；當前物件的集合成員物件中的元素；當前物件建立的物件；方法引數物件；

End .