Java設計模式（十三）別人再問你設計模式，叫他看這篇文章

時間 2019-11-17

標籤 java 設計模式十三別人再問看這文章欄目 Java 简体版

原文原文鏈接

原創文章，轉載請務註明出處java

OOP三大基本特性

封裝

封裝，也就是把客觀事物封裝成抽象的類，而且類能夠把本身的屬性和方法只讓可信的類操做，對不可信的進行信息隱藏。面試

繼承

繼承是指這樣一種能力，它可使用現有的類的全部功能，並在無需從新編寫原來類的狀況下對這些功能進行擴展。設計模式

多態

多態指一個類實例的相同方法在不一樣情形有不一樣的表現形式。具體來講就是不一樣實現類對公共接口有不一樣的實現方式，但這些操做能夠經過相同的方式（公共接口）予以調用。安全

OOD七大原則

面向對象設計（OOD）有七大原則（是的，你沒看錯，是七大原則，不是六大原則），它們互相補充。架構

開-閉原則

Open-Close Principle（OCP），即開-閉原則。開，指的是對擴展開放，即要支持方便地擴展；閉，指的是對修改關閉，即要嚴格限制對已有內容的修改。開-閉原則是最抽象也是最重要的OOD原則。簡單工廠模式、工廠方法模式、抽象工廠模式中都提到了如何經過良好的設計遵循開-閉原則。oop

里氏替換原則

Liskov Substitution Principle（LSP），即里氏替換原則。該原則規定「子類必須可以替換其父類，不然不該當設計爲其子類」。換句話說，父類出現的地方，都應該能由其子類代替。因此，子類只能去擴展基類，而不是隱藏或者覆蓋基類。學習

依賴倒置原則

Dependence Inversion Principle（DIP），依賴倒置原則。它講的是「設計和實現要依賴於抽象而非具體」。一方面抽象化更符合人的思惟習慣；另外一方面，根據里氏替換原則，能夠很容易將原則的抽象替換爲擴展後的具體，這樣能夠很好的支持開-閉原則。設計

接口隔離原則

Interface Segration Principle（ISP），接口隔離原則，「將大的接口打散成多個小的獨立的接口」。因爲Java類支持實現多個接口，能夠很容易的讓類具備多種接口的特徵，同時每一個類能夠選擇性地只實現目標接口。代理

單一職責原則

Single Responsibility Principle（SRP），單一職責原則。它講的是，不要存在多於一個致使類變動的緣由，是高內聚低耦合的一個體現。code

迪米特法則/最少知道原則

Law of Demeter or Least Knowledge Principle（LoD or LKP），迪米特法則或最少知道原則。它講的是「一個對象就儘量少的去了解其它對象」，從而實現鬆耦合。若是一個類的職責過多，因爲多個職責耦合在了一塊兒，任何一個職責的變動均可能引發其它職責的問題，嚴重影響了代碼的可維護性和可重用性。

合成/聚合複用原則

Composite/Aggregate Reuse Principle（CARP / CRP），合成/聚合複用原則。若是新對象的某些功能在別的已經建立好的對象裏面已經實現，那麼應當儘可能使用別的對象提供的功能，使之成爲新對象的一部分，而不要再從新建立。新對象可經過向這些對象的委派達到複用已有功能的效果。簡而言之，要儘可能使用合成/聚合，而非使用繼承。《Java設計模式（九）橋接模式》中介紹的橋接模式便是對這一原則的典型應用。

設計模式

什麼是設計模式

能夠用一句話歸納設計模式———設計模式是一種利用OOP的封閉、繼承和多態三大特性，同時在遵循單一職責原則、開閉原則、里氏替換原則、迪米特法則、依賴倒置原則、接口隔離原則及合成/聚合複用原則的前提下，被總結出來的通過反覆實踐並被多數人知曉且通過分類和設計的可重用的軟件設計方式。

設計模式十萬個爲何

爲何要用設計模式

設計模式是高級軟件工程師和架構師面試基本必問的項目（先經過面試進入這個門檻咱們再談其它）
設計模式是通過大量實踐檢驗的安全高效可複用的解決方案。不要重複發明輪子，並且大多數時候你發明的輪子尚未已有的好
設計模式是被主流工程師/架構師所普遍接受和使用的，你使用它，方便與別人溝通，也方便別人code review（這個夠實在吧）
使用設計模式能夠幫你快速解決80%的代碼設計問題，從而讓你更專一於業務自己
設計模式自己是對幾大特性的利用和對幾大設計原則的踐行，代碼量積累到必定程度，你會發現你已經或多或少的在使用某些設計模式了
架構師或者team leader教授初級工程師設計模式，能夠很方便的以你們承認以方式提升初級工程師的代碼設計水平，從而有利於提升團隊工程實力

是否是必定要儘量使用設計模式

每一個設計模式都有其適合範圍，並解決特定問題。因此項目實踐中應該針對特定使用場景選用合適的設計模式，若是某些場景下如今的設計模式都不能很徹底的解決問題，那也沒必要拘泥於設計模式自己。實際上，學習和使用設計模式自己並非目的，目的是經過學習和使用它，強化面向對象設計思路並用合適的方法解決工程問題。

設計模式有時並不是最優解

有些人認爲，在某些特定場景下，設計模式並不是最優方案，而本身的解決方案可能會更好。這個問題得分兩個方面來討論：一方面，如上文所述，全部設計模式都有其適用場景，「one size does not fit all」；另外一方面，確實有可能本身設計的方案比設計模式更適合，但這並不影響你學習並使用設計模式，由於設計模式通過大量實戰檢驗能在絕大多數狀況下提供良好方案。