1.什么是好的軟件設計虑鼎？軟件設計的金科玉律：復用
2.設計模式八大原則
- 依賴倒置原則（DIP）
- 高層模塊（穩(wěn)定）不應該依賴于低層模塊（變化），二者都應該依賴于抽象（穩(wěn)定）杠娱。
2. 抽象（穩(wěn)定）不應該依賴于實現(xiàn)細節(jié)（變化）廷区，實現(xiàn)細節(jié)能改依賴于抽象（抽象）嬉挡。
- 開放封閉原則（OCP）
1. 對擴展開放胚迫，對更改封閉
2. 類模塊應該是可擴展的喷户，但是不可修改。
- 單一職責原則（SRP）
- 一個類應該僅有一個引起它變化的原因访锻。
- 變化的方向隱含著類的責任褪尝。
- Liskov替換原則（LSP）
- 子類必須能夠替換他們的基類(IS-A)闹获。
- 繼承表達類型抽象。
- 接口隔離原則（ISP）
- 不應該強迫客戶程序依賴他們不用的方法河哑。
- 接口應該小而完備避诽。
- 優(yōu)先使用對象組合，而不是類繼承
1. 類繼承通常為“白箱復用”璃谨，對象組合通常為“黑箱復用”沙庐。
2. 繼承在某種程度上破壞了封裝性，子類父類耦合度高睬罗。
- 對象組合則只要求被組合的對象具有良好定義的接口轨功，耦合度底旭斥。
- 封裝變化點
- 使用封裝創(chuàng)建對象之間的分界層容达，讓設計者可以在分界層的一側(cè)進行修改，而不會對另一側(cè)產(chǎn)生不良的影響垂券，從而實現(xiàn)層次間的松耦合花盐。
- 針對接口編程，而不是針對實現(xiàn)編程
- 不將變量類型聲明為某個特定的具體類菇爪，而是聲明為某個接口算芯。
- 客戶程序無需獲知對象的具體類型，只需要知道對象所具有的接口凳宙。
- 減少系統(tǒng)中各部分的依賴關系熙揍，從而實現(xiàn)“高內(nèi)聚，松耦合”的類型設計方案氏涩。
3.設計模式
Template Method
在軟件構建過程中届囚，我們需要為某些對象建立一種“通知依賴關系”——一個對象（目標對象）的狀態(tài)發(fā)生改變，所有的依賴對象（觀察者對象）都將得到通知是尖。
定義對象間的一種一對多（變化）的依賴關系意系，以便當一個對象（Subject）的狀態(tài)發(fā)生改變時，所有依賴于它的對象都得到通知并自動更新饺汹。
Strategy
在軟件構件過程中蛔添，某些對象使用的算法可能多種多樣，經(jīng)常改變兜辞，如果將這些算法都編碼到對象中迎瞧，將會使對象變得異常負責，而且有時候支持不適用的算法也是一個性能負擔逸吵。
定義一系列算法夹攒，把他們一個個封裝起來，并且使他們可以相互替換（變化）胁塞，該模式使得算法可獨立于使用它的客戶程序（穩(wěn)定）而變化（擴展咏尝，子類化）压语。
Observer/Event
在軟件構建過程中，我們需要為某些對象建立一種“通知依賴關系”——一個對象（目標對象）的狀態(tài)發(fā)生改變编检，所有的依賴對象（觀察者對象）都將得到通知胎食。
定義對象間的一種一對多（變化）的依賴關系，以便當一個對象（Subject）的狀態(tài)發(fā)生改變時允懂，所有依賴于它的對象都得到通知并自動更新厕怜。
Decorator
在某些情況下，我們可能會“過度的使用繼承來擴展對象的功能”蕾总，由于繼承為類型引入的靜態(tài)特性粥航，使得這種擴展方式缺少靈活性，并且隨著子類的增多生百，各種子類的組合會導致更多子類的膨脹递雀。
動態(tài)（組合）的給一個對象增加一些額外的職責，就增加功能而言蚀浆，Decorator模式比生成子類（繼承）更為靈活（消除重復代碼&減少子類個數(shù)）缀程。
Bridge
由于某些類型的固有的實現(xiàn)邏輯，使得它們具有連個變化的維度市俊，乃至多個維度的變化杨凑。
將抽象部分（業(yè)務功能）與實現(xiàn)部分（平臺實現(xiàn)）分離，使它們可以獨立變化摆昧。
