面向物件的3個基本要素：封裝、繼承、多型

面向物件的5種基本設計原則

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

遵循單一職責原的優點有：

• 可以降低類的複雜度，一個類只負責一項職責，其邏輯肯定要比負責多項職責簡單的多；
• 提高類的可讀性，提高系統的可維護性；
• 變更引起的風險降低，變更是必然的，如果單一職責原則遵守的好，當修改一個功能時，可以顯著降低對其他功能的影響。

        需要說明的一點是單一職責原則不只是面向物件程式設計思想所特有的，只要是模組化的程式設計，都適用單一職責原則。

開放封閉原則（Open-Close Principle）

里氏替換原則（Liskov-Substituion Principle）

其核心思想是：子類必須能夠替換其基類。這一思想體現為對繼承機制的約束規範，只有子類能夠替換其基類時，才能保證系統在執行時期內識別子類，這是保證繼承複用的基礎。在父類和子類的具體行為中，必須嚴格把握繼承層次中的關係和特徵，將基類替換為子類，程式的行為不會發生任何變化。同時，這一反過來則是不成立的。 里氏替換原則，主要著眼於對抽象和多型建立在繼承的基礎上，因此只有遵循了里氏替換原則，才能保證繼承複用是可靠的。

實現的方法是面向介面程式設計，將公共部分抽象為基類介面或抽象類，通過繼承抽象類，在子類中通過複寫父類的方法實現新的方式支援同樣的職責。 里氏替換原則是關於繼承機制的設計原則，違反了里氏替換就必然導致違反了開閉原則。 里氏替換原則能夠保證系統具有良好的拓展性，同時實現基於多型的抽象機制，能夠減少程式碼冗餘，避免執行期的型別判別

子類可以實現父類的抽象方法，但不能覆蓋父類的非抽象方法。

子類中可以增加自己特有的方法。

當子類的方法過載父類的方法時，方法的前置條件（即方法的形參）要比父類方法的輸入引數更寬鬆。

當子類的方法實現父類的抽象方法時，方法的後置條件（即方法的返回值）要比父類更嚴格。

依賴倒置原則（Dependecy-Inversion Principle）

高層模組不應該依賴低層模組，二者都應該依賴其抽象；抽象不應該依賴細節；細節應該依賴抽象

    其核心思想是：依賴於抽象。具體而言就是高層模組不依賴於底層模組，二者都同依賴於抽象；抽象不依賴於具體，具體依賴於抽象。
    我們知道，依賴一定會存在於類與類、模組與模組之間。當兩個模組之間存在緊密的耦合關係時，最好的方法就是分離介面和實現：在依賴之間定義一個抽象的介面使得高層模組呼叫介面，而底層模組實現介面的定義，以此來有效控制耦合關係，達到依賴於抽象的設計目標。
    抽象的穩定性決定了系統的穩定性，因為抽象是不變的，依賴於抽象是面向物件設計的精髓，也是依賴倒置原則的核心。
    依賴於抽象是一個通用的原則，而某些時候依賴於細節則是在所難免的，必須權衡在抽象和具體之間的取捨，方法不是一層不變的。依賴於抽象，就是對介面程式設計，不要對實現程式設計。

介面隔離原則（Interface-Segregstion Principle）

    其核心思想是：使用多個小的專門的介面，而不要使用一個大的總介面。
    具體而言，介面隔離原則體現在：介面應該是內聚的，應該避免“胖”介面。一個類對另外一個類的依賴應該建立在最小的介面上，不要強迫依賴不用的方法，這是一種介面汙染。
    介面有效地將細節和抽象隔離，體現了對抽象程式設計的一切好處，介面隔離強調介面的單一性。而胖介面存在明顯的弊端，會導致實現的型別必須完全實現介面的所有方法、屬性等；而某些時候，實現型別並非需要所有的介面定義，在設計上這是“浪費”，而且在實施上這會帶來潛在的問題，對胖介面的修改將導致一連串的客戶端程式需要修改，有時候這是一種災難。在這種情況下，將胖介面分解為多個特點的定製化方法，使得客戶端僅僅依賴於它們的實際呼叫的方法，從而解除了客戶端不會依賴於它們不用的方法。
    分離的手段主要有以下兩種：1、委託分離，通過增加一個新的型別來委託客戶的請求，隔離客戶和介面的直接依賴，但是會增加系統的開銷。2、多重繼承分離，通過介面多繼承來實現客戶的需求，這種方式是較好的。

    以上就是5個基本的面向物件設計原則，它們就像面向物件程式設計中的金科玉律，遵守它們可以使我們的程式碼更加鮮活，易於複用，易於拓展，靈活優雅。不同的設計模式對應不同的需求，而設計原則則代表永恆的靈魂，需要在實踐中時時刻刻地遵守。就如ARTHUR J.RIEL在那邊《OOD啟示錄》中所說的：“你並不必嚴格遵守這些原則，違背它們也不會被處以宗教刑罰。但你應當把這些原則看做警鈴，若違背了其中的一條，那麼警鈴就會響起。