物件導向編程的軟體設計原則

標籤：

         在開始Android軟體實際APP開始之前，我們須要對物件導向設計原則及設計模式做一個初步的瞭解。才幹在以後的實戰過程中，少走彎路。使我們的軟體開發生涯感覺到快樂、輕鬆。好了，廢話少說，咱們今天給大家一起探討一下軟OOP中的軟體開發設計原則。這些東東都是OOP的設計精髓，他們蘊藏著前輩留下的產物。眼下。軟體設計最基本原則有下面幾種（總共同擁有11種）：單一職責原則、開放封閉原則、依賴倒置原則、介面隔離原則和裡氏替換（Liskov替換）原則

       單一職責原則

        就是一個類值做一件事情。引起它發生變化的僅僅有一個。

我們常常會聽到一個詞語“高內聚、低耦合”。我們將職責定義為引起變化的原因。以提高內聚性來降低引起變化的原因。

若是職責越多，耦合性就會越高；我們略微哪個地方有修改，都會波及到其它的類。

       開放封閉原則

      地方詳細體如今：對擴充開發、對改動關閉。

什麼意思呢？對擴充開放，意味著有新的需求或變化時，能夠對現有代碼進行擴充。以適應新的情況；對改動封閉。意味著類一旦設計完畢。就能夠獨立完畢其工作，而不要對其進行不論什麼嘗試的改動。

       事實上，我們在實際的編程過程中，用的最多。

您想想：一般我們在設計的時候，我們會設計抽象類別、介面（行為）；然後詳細的實作類別是通過繼承的方式；我們通過覆寫的方式來編寫不同詳細的實作類別的方法；這就是此設計原則的真實寫照。

      依賴倒置原則

      其核心思想是：依賴於抽象。

詳細而言就是高層模組不依賴於底層模組，二者都同依賴於抽象；抽象不依賴於詳細，詳細依賴於抽象。當兩個模組之間存在緊密的耦合關係時，最好的方法就是分離介面和實現：在依賴之間定義一個抽象的介面使得高層模組調用介面。而底層模組實現介面的定義，以此來有效控制耦合關係，達到依賴於抽象的設計目標。

抽象的穩定性決定了系統的穩定性，由於抽象是不變的，依賴於抽象是物件導向設計的精髓，也是依賴倒置原則的核心。依賴於抽象是一個通用的原則。而某些時候依賴於細節則是在所難免的，必須權衡在抽象和詳細之間的取捨。方法不是一層不變的。依賴於抽象，就是對介面編程。不要對實現編程。

 

      介面隔離原則

      其核心思想是：使用多個小的專門的介面，而不要使用一個大的總介面。我們在設計介面的時候。詳細而言，介面隔離原則體如今：介面應該是內聚的，應該避免“胖”介面。一個類對另外一個類的依賴應該建立在最小的介面上，不要強迫依賴不用的方法，這是一種介面汙染。

    裡氏替換（Liskov替換）原則

      不論什麼基類能夠出現的地方，子類一定能夠出現。LSP是繼承複用的基石。僅僅有當子類能夠替換基類，軟體單位的功能不受影響時，基類才幹真正的被複用，而子類也能夠在基類的基礎上添加新的行為。Liskov替換原則，主要著眼於對抽象和多態建立在繼承的基礎上，因此僅僅有遵循了Liskov替換原則。才幹保證繼承複用是可靠地。實現的方法是面向介面編程：將公用部分抽象為基類介面或抽象類別，通過Extract Abstract Class。在子類中通過覆寫父類的方法實現新的方式支援相同的職責。

物件導向編程的軟體設計原則