OOP三大基本特性

封裝

封裝，也就是把客觀事物封裝成抽象的類，並且類可以把自己的屬性和方法只讓可信的類操作，對不可信的進行資訊隱藏。

繼承

繼承是指這樣一種能力，它可以使用現有的類的所有功能，並在無需重新編寫原來類的情況下對這些功能進行擴充套件。

多型

多型指一個類例項的相同方法在不同情形有不同的表現形式。具體來說就是不同實現類對公共介面有不同的實現方式，但這些操作可以通過相同的方式（公共介面）予以呼叫。

OOD七大原則

物件導向設計（OOD）有七大原則（是的，你沒看錯，是七大原則，不是六大原則），它們互相補充。

開-閉原則

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

里氏替換原則

Liskov Substitution Principle（LSP），即里氏替換原則。該原則規定“子類必須能夠替換其父類，否則不應當設計為其子類”。換句話說，父類出現的地方，都應該能由其子類代替。所以，子類只能去擴充套件基類，而不是隱藏或者覆蓋基類。

依賴倒置原則

Dependence Inversion Principle（DIP），依賴倒置原則。它講的是“設計和實現要依賴於抽象而非具體”。一方面抽象化更符合人的思維習慣；另一方面，根據里氏替換原則，可以很容易將原來的抽象替換為擴充套件後的具體，這樣可以很好的支援開-閉原則。

介面隔離原則

Interface Segration Principle（ISP），介面隔離原則，“將大的介面打散成多個小的獨立的介面”。由於Java類支援實現多個介面，可以很容易的讓類具有多種介面的特徵，同時每個類可以選擇性地只實現目標介面。

單一職責原則

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

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

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”；另一方面，確實有可能自己設計的方案比設計模式更適合，但這並不影響你學習並使用設計模式，因為設計模式經過大量實戰檢驗能在絕大多數情況下提供良好方案。

設計模式太教條化

設計模式雖然都有其相對固定的實現方式，但是它的精髓是利用OOP的三大特性，遵循OOD七大原則解決工程問題。所以學習設計模式的目的不是學習設計模式的固定實現方式本身，而是其思想。

我有自己的一套思路，沒必要引導團隊成員學習設計模式

設計模式是被廣泛接受和使用的，引導團隊成員使用設計模式可以減少溝通成本，而更專注於業務本身。也許你有自己的一套思路，但是你怎麼能保證團隊成員一定認可你的思路，進而將你的思路貫徹實施呢？統一使用設計模式能讓團隊只使用20%的精力決解80%的問題。其它20%的問題，才是你需要花精力解決的。

轉載請務必將下面這段話置於文章開頭處（保留超連結）。

本文轉發自技術世界，原文連結　http://www.jasongj.com/design_pattern/summary/