面向對象的6條設計原則

目錄

• • 一 面向對象的6條設計原則
  • • 1 單一職責原則
    • 2 開放封閉原則
    • 3 依賴倒置原則
    • 4 Liskov替換原則
    • 5 接口隔離原則
    • 6 迪米特原則
  • 二 依賴注入
  • • 1 控制反轉（IoC）
    • 2 依賴注入（DI）
    • 3 IoC容器
    • 4 文章
  • 三 代碼可擴充性
  • 四 簡單工廠模式--SimpleFactory
  • 五 uml

一 面向對象的6條設計原則

  OOP(面向對象程式設計(Object Oriented Programming，OOP，面向對象程式設計)是一種計算機程式設計架構。)基本上有6大原則，而實際上都是互補的，也就是說一些原則需要利用另一些原則來實作自己。6大原則如下：

1 單一職責原則

  單一職責原則：一個類，最好隻做一件事，隻有一個引起它的變化。可以看做是低耦合、高内聚在面向對象原則上的引申，将職責定義為引起變化的原因，以提高内聚性來減少引起變化的原因。

  職責過多，可能引起它變化的原因就越多，這将導緻職責依賴，互相之間就産生影響，進而大大損傷其内聚性和耦合度。通常意義下的單一職責，就是指隻有一種單一功能，不要為類實作過多的功能點，以保證明體隻有一個引起它變化的原因。

  如果能夠想到多于一個的動機去改變一個類， 那麼這個類就具有多于一個的職責，就應該考慮類的職責分離。

2 開放封閉原則

  是面向對象所有原則的核心，軟體設計說到底追求的目标就是封裝變化、降低耦合，而開放封閉原則就是這一目标的最直接展現。

  開放封閉原則：軟體實體應該是可擴充的，而不可修改的。也就是，對擴充開放，對修改封閉的。開放封閉原則主要展現在兩個方面：1、對擴充開放，意味着有新的需求或變化時，可以對現有代碼進行擴充，以适應新的情況。2、對修改封閉，意味着類一旦設計完成，就可以獨立完成其工作，而不要對其進行任何嘗試的修改。

  在我們最初編寫代碼時， 假設變化不會發生，當變化發生時， 我們就建立抽象來隔離以後發生的同類變化。通過一些面向對象的手段，如繼承，多态等來隔離具體實作，需求依然可以滿足，還能應對變化。即面對需求， 對程式的改動是通過增加新代碼進行的， 而不是更改現有的代碼。

3 依賴倒置原則

  依賴倒置原則：針對接口程式設計， 不要對實作程式設計。

A. 高層子產品不應該依賴層子產品，兩個都應該依賴抽象。

B. 抽象不應該依賴細節，細節應該依賴抽象。

  依賴倒轉其實可以說是面向對象設計的标志，編寫時考慮的都是如何針對抽象程式設計而不是針對細節程式設計。即程式中所有的依賴關系都是終止于抽象類或者接口，那就是面向對象的設計，反之那就是過程化的設計了。

4 Liskov替換原則

  子類必須能夠替換其基類。這一思想展現為對繼承機制的限制規範，隻有子類能夠替換基類時，才能保證系統在運作期内識别子類，這是保證繼承複用的基礎。在父類和子類的具體行為中，必須嚴格把握繼承層次中的關系和特征，将基類替換為子類，程式的行為不會發生任何變化。同時，這一限制反過來則是不成立的，子類可以替換基類，但是基類不一定能替換子類。

  Liskov替換原則，主要着眼于對抽象和多态建立在繼承的基礎上，是以隻有遵循了Liskov替換原則，才能保證繼承複用是可靠地。實作的方法是面向接口程式設計：将公共部分抽象為基類接口或抽象類，通過Extract Abstract Class，在子類中通過覆寫父類的方法實作新的方式支援同樣的職責。

  Liskov替換原則是關于繼承機制的設計原則，違反了Liskov替換原則就必然導緻違反開放封閉原則。

  Liskov替換原則能夠保證系統具有良好的拓展性，同時實作基于多态的抽象機制，能夠減少代碼備援，避免運作期的類型判别。

5 接口隔離原則

  核心思想是：使用多個小的專門的接口，而不要使用一個大的總接口。

  具體而言，接口隔離原則展現在：接口應該是内聚的，應該避免“胖”接口。一個類對另外一個類的依賴應該建立在最小的接口上，不要強迫依賴不用的方法，這是一種接口污染。

  接口有效地将細節和抽象隔離，展現了對抽象程式設計的一切好處，接口隔離強調接口的單一性。而胖接口存在明顯的弊端，會導緻實作的類型必須完全實作接口的所 有方法、屬性等；而某些時候，實作類型并非需要所有的接口定義，在設計上這是“浪費”，而且在實施上這會帶來潛在的問題，對胖接口的修改将導緻一連串的客 戶端程式需要修改，有時候這是一種災難。在這種情況下，将胖接口分解為多個特點的定制化方法，使得用戶端僅僅依賴于它們的實際調用的方法，進而解除了客戶 端不會依賴于它們不用的方法。

  分離的手段主要有以下兩種：1、委托分離，通過增加一個新的類型來委托客戶的請求，隔離客戶和接口的直接依賴，但是會增加系統的開銷。2、多重繼承分離，通過接口多繼承來實作客戶的需求，這種方式是較好的。

6 迪米特原則

  如果兩個類不必彼此直接通信， 那麼這兩個類就不應當發生直接的互相作用。如果其中一個類需要調用另一個類的某一個方法的話，可以通過第三者轉發這個調用。迪米特法則其根本思想， 是強調了類之間的松耦合。

  迪米特法則首先強調的前提是在類的結構設計上，每一個類都應當盡量降低成員的通路權限，也就是說, 一個類包裝好自己的 private 狀态， 不需要讓别的類知道的字段或行為就不要公開。

  在程式設計時，類之間的耦合越弱，越有利于複用，一個處在弱耦合的類被修改，不會對有關系的類造成波及。也就是說，資訊的隐藏促進了軟體的複用。

二 依賴注入

  OOD有一個重要的思想那就是依賴倒置原則（DIP），并由此引申出IoC、DI以及Ioc容器等概念。

  依賴倒置原則（DIP）: 一種軟體架構設計的原則（抽象概念）。

  控制反轉（IoC）：一種反轉流、依賴和接口的方式（DIP的具體實作方式）。

  依賴注入（DI）：IoC的一種實作方式，用來反轉依賴（IoC的具體實作方式）。

  IoC容器 ：依賴注入的架構，用來映射依賴，管理對象建立和生存周期（DI架構）。

  依賴倒置原則（DIP）：高層子產品不依賴于底層子產品的實作，而低層子產品依賴于高層子產品定義的接口。

1 控制反轉（IoC）

   DIP是一種 軟體設計原則，它僅僅告訴你兩個子產品之間應該如何依賴，但是它并沒有告訴如何做。IoC則是一種 軟體設計模式，它告訴你應該如何做，來解除互相依賴子產品的耦合。控制反轉（IoC），它為互相依賴的元件提供抽象，将依賴（低層子產品）對象的獲得交給第三方（系統）來控制，即依賴對象不在被依賴子產品的類中直接通過new來擷取。

2 依賴注入（DI）

  控制反轉（IoC）一種重要的方式，就是将依賴的對象的建立和綁定轉移到被依賴對象類的外部來實作。

  依賴注入（DI），它提供一種機制，将被依賴（低層子產品）對象的引用傳遞給依賴（高層子產品）對象。

  方法一 構造函數注入： 在需要依賴的對象的構造函數中增加一個接口參數，在執行個體化需要依賴的對象時，将被依賴對象傳入。

  方法二 方法注入： 同上，通過方法實作。

3 IoC容器

  上面所有的例子中，我們都是通過手動的方式來建立被依賴對象，并将其傳遞給依賴子產品

  對于大型項目來說，互相依賴的元件比較多。如果還用手動的方式，自己來建立和注入依賴的話，顯然效率很低，而且往往還會出現不可控的場面。正因如此，IoC容器誕生了。IoC容器實際上是一個DI架構，它能簡化我們的工作量。它包含以下幾個功能：動态建立、注入依賴對象。管理對象生命周期。映射依賴關系。

4 文章

  談談對Spring IOC的了解：https://blog.csdn.net/qq_22654611/article/details/52606960/

三 代碼可擴充性

  當需求變化時，需要對目前程式進行改變，使代碼可以改變。這被稱為可擴充性。可擴充的代碼将允許您快速添加或删除功能，而不會引入錯誤。在一個完美的可擴充的世界中，我們可以添加新的功能，而不用改變任何已經存在的代碼。

  白箱可擴充性：在源碼級别的代碼擴充。黑箱可擴充性：：擴充現有系統而不直接擴充其原始代碼，源代碼通常不可見，提供文檔和約定。到了黑箱這一步，才算真正滿足OCP原則。

  開放原則 - 開放擴充，關閉修改。使代碼(類，功能)的機關，使他們永遠不必再被觸摸。

  分離原則 - 保持代碼的一緻性；保持代碼松耦合；最小化備援；使用單元測試來查找代碼氣味；使用多态性；有利于繼承的構成；使用依賴注入來分隔使用和建立。

四 簡單工廠模式–SimpleFactory

  本節内容來自這裡。

五 uml

  本節内容來自這裡。

  統一模組化語言（Unified Modeling Language，UML）又稱标準模組化語言，是始于1997年的一個OMG标準，它是一個支援模型化和軟體系統開發的圖形化語言，為軟體開發的所有階段提供模型化和可視化支援，包括由需求分析到規格，到構造和配置。‘UML感興趣的可以閱讀UML 1規 範，包含了UML 的所有知識内容。

  注：OMG, Object Management Group 對象管理組織