設計模式梗概

設計模式簡介

      1.設計模式是許多軟件開發者在長時間的開發生涯中對面臨的常見問題的解決方案的經驗總結,代表了一種最佳實踐

      2.使用設計模式是爲了更好的複用代碼,讓代碼更好的被他人理解,保證代碼的可靠性。同時也保證了代碼一定的規範性

      3.每種模式在現實中都有相應的原理來與之對應,每種模式都描述了一個在我們周圍不斷重複發生的問題以及該問題的核心解決方案在項目中合理的運用設計模式可以解決許多問題,這也是設計模式大受歡迎的原因所在。但在使用方面主要取決於一個程序員的經驗

設計模式的兩大核心原理

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

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

     組合對象和繼承的區別

      面向對象系統中功能複用的兩種最常用技術是類繼承和對象組合(object composition)。正如我們已解釋過的,類繼承允許你根據其他類的實現來定義一個類的實現。這種通過生成子類的複用通常被稱爲白箱複用(white-box reuse)。術語“白箱”是相對可視性而言:在繼承方式中,父類的內部細節對子類可見。

  對象組合是類繼承之外的另一種複用選擇。新的更復雜的功能可以通過組裝或組合對象來獲得(將其他對象作爲新對象的屬性出現)。對象組合要求被組合的對象具有良好定義的接口。這種複用風格被稱爲黑箱複用(black-box reuse),因爲對象的內部細節是不可見的。對象只以“黑箱”的形式出現。

        繼承和組合各有優缺點。類繼承是在編譯時刻靜態定義的,且可直接使用,因爲程序設計語言直接支持類繼承。類繼承可以較方便地改變被複用的實現。當一個子類重定義一些而不是全部操作時,它也能影響它所繼承的操作,只要在這些操作中調用了被重定義的操作。

        但是類繼承也有一些不足之處。首先,因爲繼承在編譯時刻就定義了,所以無法在運行時刻改變從父類繼承的實現。更糟的是,父類通常至少定義了部分子類的具體表示。因爲繼承對子類揭示了其父類的實現細節,所以繼承常被認爲“破壞了封裝性” 。子類中的實現與它的父類有如此緊密的依賴關係,以至於父類實現中的任何變化必然會導致子類發生變化。當你需要複用子類時,實現上的依賴性就會產生一些問題。如果繼承下來的實現不適合解決新的問題,則父類必須重寫或被其他更適合的類替換。這種依賴關係限制了靈活性並最終限制了複用性。一個可用的解決方法就是隻繼承抽象類,因爲抽象類通常提供較少的實現。

        對象組合是通過獲得對其他對象的引用而在運行時刻動態定義的。組合要求對象遵守彼此的接口約定,進而要求更仔細地定義接口,而這些接口並不妨礙你將一個對象和其他對象一起使用。這還會產生良好的結果:因爲對象只能通過接口訪問,所以我們並不破壞封裝性;只要類型一致,運行時刻還可以用一個對象來替代另一個對象;更進一步,因爲對象的實現是基於接口寫的,所以實現上存在較少的依賴關係。

  對象組合對系統設計還有另一個作用,即優先使用對象組合有助於你保持每個類被封裝,並被集中在單個任務上。這樣類和類繼承層次會保持較小規模,並且不太可能增長爲不可控制的龐然大物。另一方面,基於對象組合的設計會有更多的對象 (而有較少的類),且系統的行爲將依賴於對象間的關係而不是被定義在某個類中。

設計模式的分類

         1.創建型模式:這些設計模式提供了一種在創建對象的同時隱藏創建邏輯的方式,而不是使用 new 運算符直接實例化對象。這使得程序在判斷針對某個給定實例需要創建哪些對象時更加靈活

         2.結構型模式:這些設計模式關注類和對象的組合。繼承的概念被用來組合接口和定義組合對象獲得新功能的方式

         3.行爲型模式:這些設計模式特別關注對象之間的通信,或者說關注點在方法的定義上。

設計模式七大原則      

       1、開閉原則(Open Close Principle)

       開閉原則的意思是:對擴展開放,對修改關閉。在程序需要進行拓展的時候,儘量增加代碼而不是修改原有代碼。

      2、里氏替換原則(Liskov Substitution Principle)

      里氏代換原則是面向對象設計的基本原則之一。 繼承使父類和子類之間的耦合加深,里氏替換原則告訴我們應該儘量使用依            賴,聚合,組合等手段來代替繼承解決問題,一定要繼承,子類也儘量不要重寫父類的方法。

      3、依賴倒轉原則(Dependence Inversion Principle)

      這個原則是開閉原則的基礎,具體內容:針對接口編程,依賴於抽象而不依賴於具體。

      4、接口隔離原則(Interface Segregation Principle)

      這個原則的意思是:使用多個隔離的接口,比使用單個接口要好。換一種說法就是一個類不應該依賴它不需要的接口,即一個          類對另一個類的依賴應該建立在最小的接口上    

     5、迪米特法則,又稱最少知道原則(Demeter Principle)

      最少知道原則是指:即一個類對自己依賴的類知道的越少越好。也就是說,對於被依賴的類不管多麼複雜,都儘量將邏輯封裝          在類的內部。對外除了提供的 public 方法,不對外泄露任何信息

     6、合成複用原則(Composite Reuse Principle)

     合成複用原則是指:儘量使用合成/聚合的方式,而不是使用繼承。

     7.  單一職責原則

     對類來說的,即一個類應該只負責一項職責。如類 A 負責兩個不同職責:職責 1,職責 2。當職責 1 需求變更 而改變 A 時,可能       造成職責 2 執行錯誤,所以需要將類 A 的粒度分解爲 A1,A2

總結

設計模式分爲3大類,共23種。我們需要明確的是設計模式只是儘量往上述的七大原則靠近,並不是說每一種設計模式都完全遵守上述七種設計原則,在我們的日常開發中,應儘量站在軟件的角度去開發這樣你就會體會到設計模式的好處,但是職業生涯的初期,很多人都是站在實現功能的角度去看,這樣設計模式有的時候甚至會顯得像是一種累贅,因爲很多時候,從實現功能的角度而言我們寫的代碼更少。還有一個需要明確的是我們設計模式沒有好壞之分,只有合適與否,我們應該根據實際業務需求選擇合適的設計模式。總之,關於設計模式的思想精髓還是需要我們在日常的開發中慢慢體會。

 

 

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章