軟件設計中的基本共識：
1.高內聚，低耦合：如果想使軟件系統架構穩定那麼我們期望軟件的各模塊內元素結合的緊密，而模塊之間的耦合度（關聯性）越低越好。高內聚不僅體現在模塊上，單獨的類或方法也應該是內聚的。
2.面向抽象編程：面向過程開發中，上層組件調用下層組件，這意味着當下層組件發生劇烈變化時，上層組件也得跟着一起變化，增加了維護成本。面向對象的設計中，我們努力使程序依賴抽象，而不去依賴具體實現，首先依賴抽象降低了模塊間實現細節的耦合度，其次抽象變化的概率比較小，修改具體實現不影響其他模塊，見底了風險成本，提升了軟件結構的健壯性。
3.多用組合少用繼承：組合和繼承都是對已有屬性和功能的複用，繼承偏向於擴展，組合偏向於使用。組合的好處在於其方式更加靈活，不會對類造成危害，不會造成膨脹，同時減少了對父類的依賴。少用繼承而不是不用繼承，使用繼承結構的代碼可讀性更高，一般認爲繼承結構不應該超過4層，而且應該謹慎的使用修飾符【附1】。
4.開閉原則：軟件設計中主張“對擴展開放，對修改關閉”，該原則倡導我們隊軟件實體進行拓展時，儘量不要去修改原有的軟件實體進行修改。
對以上共識具體化和規範化就有了設計模式的六大原則：
1.開閉原則：一個軟件實體應該對擴展開放，對修改關閉。
2.單一職責原則：一個類應該只有一個引起它變化的原因。
3.依賴倒置原則：要依賴要抽象，而不要依賴於具體實現。
4.接口隔離原則：使用多個隔離的接口，分離不同的藉口行爲，也就是說一個類對另外類的依賴性應該建立在最小接口上。
5.里氏替換原則：繼承必須保證基類所擁有的性質在子類中仍然成立，即子類應當替換任何基類能夠出現的地方。
6.迪米特法則：只和密友交談。即一個軟件實體應該儘可能少的與其他實體發生相互作用。
本篇文章主要是用來回顧下軟件設計中的各個原則，也就沒有Po上代碼來做演示（主要是演示設計模式的代碼量有點大），談談個人對六大原則的看法：
開閉原則告訴我們新增一個類而不是修改原有類來達到迭代效果，但是很遺憾現實中很難做到，首先該原則的前提是軟件一開始就有一個很好的架構，研發人員都精心的維護這個架構，其次要求產品部懂得這個架構，不去提特別妖嬈的需求。
單一職責原則，還是很好理解並且值得我們注意的，保證模塊的單一職責想必大多數程序員都可以做到，方法的單一職責也很好理解，但是大多數人卻沒有做好：表現在一個公共方法被分解成了私有的幾個獨立的子方法，而子方法裏面居然可以繼續往下分好幾層，那麼這些子方法真的是單一職責麼，如果真的必要這樣，是不是可以用上下文參數來減少分層，順帶說一句隨意分層的代碼還嚴重降低了可讀性。
依賴倒置原則和接口隔離原則，確保你有一個好的抽象接口，而一般好的接口總是最小的，檢驗的方法就是看看你接口的實現類是不是真的需要實現每一個方法。
里氏替換原則，子類應當替換任何基類能夠出現的地方。
迪米特法則，在實踐中沒有具體運用到，但是還是能夠想到的，我引用的類越少，那麼可能導致我做改變的因素就越少。
附：1.JAVA 修飾符作用範圍
