1.面向對象的設計原則
單一職責原則、開閉原則、里氏代換原則 、依賴倒置原則、接口隔離原則、合成/聚合複用原則、迪米特法則
（1）單一職責原則（SRP）
一個類，只有一個引起它變化的原因
如果一個類有一個以上的職責，這些職責就耦合在了一起
當一個職責發生變化時，可能會影響其它的職責
多個職責耦合在一起，會影響複用性
SRP中，把職責定義爲“變化的原因”
將業務規則和持久化的控制分離
Façade和Proxy模式進行重構
（2）開閉原則（OCP）
軟件實體（類、模塊、函數等）應該是可以擴展的，但是不可修改
遵循開放-封閉原則設計的兩個主要特徵
–對於擴展是開放的
–對於更改是封閉的
好處
–可複用性好
軟件完成以後，仍然可以對軟件進行擴展，加入新的功能，非常靈活 。因此，這個軟件系統就可以通過不斷地增加新的組件，來滿足不斷變化的需求。
–可維護性好
由於對於已有的軟件系統的組件，特別是它的抽象底層不去修改，因此，我們不用擔心軟件系統中原有組件的穩定性，這就使變化中的軟件系統有一定的穩定性和延續性
特例：STRATEGY模式：既開放又封閉的Client
（3）里氏代換原則（LSP）
子類必須能夠替換掉它們的基類型
里氏代換原則是對“開-閉”原則的補充
如果兩個具體的類A，B之間的關係違反了LSP的設計
–創建一個新的抽象類C，作爲兩個具體類的超類，將A，B的共同行爲移動到C中來解決問題
–從B到A的繼承關係改爲委派關係
在進行設計的時候，我們儘量從抽象類繼承，而不是從具體類繼承
長方形和正方形的例子不滿足LSP
OOD的IS-A關係是就行爲方式而言的，行爲方式是可以進行合理假設的，是客戶程序設計所依賴的
（4）依賴倒置原則（DIP）
高層模塊不應該依賴於底層模塊，二者都應該依賴於抽象
抽象不應該依賴於細節。細節應該依賴於抽象
Hollywood原則: “Don‘t call us, we’ll call you”.程序中所有的依賴關係都應該終止於抽象類和接口針對接口而非實現編程
依賴於抽象的啓發式規則：
任何變量都不應該持有一個指向具體類的指針或引用
任何類都不應該從具體類派生
任何方法都不應該覆寫他任何基類中的已經實現了的方法
（5）接口隔離原則（ISP）
使用多個專門的接口比使用單一的總接口要好
一個類對另外一個類的依賴性應當是建立在最小的接口上的
一個接口代表一個角色，不應當將不同的角色都交給一個接口
不應該強迫客戶依賴於它們不用的方法。接口屬於客戶，不屬於它所在的類層次結構
滿足接口隔離原則,調用者只能訪問它自己的方法,不能訪問到不應該訪問的方法
（6）合成/聚合複用原則（CARP）
合成（Composition）和聚合（Aggregation）都是關聯（Association）的特殊種類。聚合表示整體和部分的關係，表示“擁有 ”；合成則是一種更強的“擁有”，部分和整體的生命週期一樣
在OOD中，有兩種基本的辦法可以實現複用
合成/聚合
繼承
HAS-A而非IS-A
（7）迪米特法則（LoD）
迪米特法則可以簡單說成：talk only to your immediate friends
一個軟件實體應當儘可能少的與其他實體發生相互作用。每一個軟件單位對其他的單位都只有最少的知識，而且侷限於那些與本單位密切相關的軟件單位
迪米特法則的初衷在於降低類之間的耦合
設計模式的門面模式（Facade）和中介模式（Mediator），都是迪米特法則應用的例子
2.面向對象的高效編程原則
避免創建重複對象
消除過期的對象引用
避免使用終結函數
爲所有導出API的元素編寫文檔註釋
使類和成員的可訪問能力最小化
複合優先於繼承
接口優先於抽象類
定義內部類：優先考慮靜態成員類
設計模式可以看http://blog.csdn.net/ydx115600497/article/details/52079826等一系列設計模式
