面向對象設計模式與原則

最近在學習李建忠老師一系列的關於面向對象設計模式的課程，就想着把總結下來，以便本身之後的學習，設計模式是一個比較空洞的話題，隨着咱們的編程經驗的積累，咱們能增長對它的理解，這是一個日積月累的過程，可是咱們應該在平時的編程過程當中學會思考和分析，想想在某種特定的場景下使用什麼樣的設計模式，怎樣才能作到代碼的易擴展和維護，這都是咱們要思考的問題，因此掌握好設計模式能對咱們的編程起到很大的做用，能讓咱們寫出來的代碼很美。

設計模式描述了軟件設計過程當中某一類常見問題的通常性的解決方案，面向對象的設計模式描述了面向對象設計過程當中，特定場景下，類與相互通訊的對象之間常見的組織關係。

設計模式與面向對象

1.面向對象設計模式解決的是「類與相互通訊的對象之間的組織關係」，包括他們的角色、職責、協做方式幾個方面

2.面向對象的設計模式是「好的面向對象設計」，所謂「好的面向對象設計」是那些能夠知足」應對變化，提升複用「的設計。

3.面向對象設計模式描述的是軟件設計，所以它是獨立於編程語言的，可是面向對象設計模式的最終實現仍然須要使用面向對象編程語言來表達。

4.面向對象設計模式不像算法技巧，能夠照常搬用，它是創建在對」面向對象「純熟、深刻的理解的接觸上的經驗性認識。掌握面向對象設計模式的前提是首先掌握」面向對象「！

從編程語言直觀瞭解面向對象

1.各類面向對象編程語言相互有別，但都能看到他們面向對象三大機制的支持，即：」封裝，繼承，多態「。封裝：隱藏內部的實現；繼承:代碼的複用；多態：改寫對象的行爲

2.使用面向對象編程語言（如C#）,能夠推進程序員以面向對象的思惟來思考軟件設計結構，從而強化面向對象的編程範式。

3.C#是一門支持面向對象編程的優秀語言，包括：各類級別的封裝支持；單實現繼承+多實現接口；抽象方法與虛方法重寫

可是經過面向對象編程語言（OOPL）認識到的面向對象，並非面向對象的所有，甚至只是擱淺的面向對象。OOPL的三大機制」封裝，繼承，多態「能夠表達面向對象的全部概念，但這三大機制自己並無刻畫出面向對象的核心精神。換言之，不是使用了面向對象的語言就實現了面向對象的設計與開發!所以咱們不能依賴編程語言的面向對象機制，來掌握面向對象。OOPL沒有回答面向對象的根本性問題——咱們爲何要使用面向對象？咱們應該怎樣使用三大機制來實現」好的面向對象「？咱們應該遵循什麼樣的面向對象原則？

從設計原則到設計模式

1.針對接口編程，而不是針對實現編程

   客戶程序無需知道所使用對象的特定類型，只須要知道對象擁有客戶所指望的接口

2.優先使用對象組合而不是類繼承

    類繼承一般是」白箱複用「，對象組合一般爲」黑箱複用「。繼承在某種程度上破壞了封裝性，子類父類耦合度高；而對象組合只要求被組合的對象具備良好定義的接口，耦合度低。

3.封裝變化點

   使用封裝來建立對象之間的分界層，讓設計者能夠在分界層的一側進行修改，而不會對另外一側產生不良的影響，從而實現層次間的低耦合。

4.使用重構獲得模式

   設計模式的應用不易先入爲主，一上來就使用設計模式是對設計模式的一大誤用。沒有一步到位的設計模式。敏捷軟件開發實踐提倡的」Refactoring to Patterns（重構到模式）「是目前廣泛認爲最好的使用設計模式的方法。

幾條更具體的設計原則

單一職責原則（SRP）

  一個類應該僅有一個引發它變化的緣由

開放封閉原則（OCP）

  類模塊應該是可擴展的，可是不可修改（對擴展開放，對更改封閉）

Liskov替換原則（LSP）

  子類必須可以替換他們的基類

依賴倒置原則（DIP）

  高層模塊不該該依賴於底層模塊，兩者應該依賴於抽象

  抽象不該該依賴於實現細節，實現細節應該依賴於抽象

接口隔離原則（ISP）

  不該該強迫客戶程序依賴於他們不用的方法