一、單一職責原則
單一職責原則：一個類只負責一個功能領域中的相應職責很泊。或者說沾谓，就一個類而言委造，應該只有一個引起它變化的原因。
單一職責原則就是說均驶，一個類不能太不能負責太多的功能昏兆，再簡單點，就是人的器官妇穴，在每個器官的功能職責是不一樣的爬虱，例如心臟就負責為人體提供血液，肺代表呼吸腾它，在軟件開發(fā)中跑筝，一個類（大到模塊，小到方法）承擔的職責越多瞒滴，它被復用的可能性就越小曲梗，而且一個類承擔的職責過多，就相當于將這些職責耦合在一起妓忍，當其中一個職責變化時稀并，可能會影響其他職責的運作，因此要將這些職責進行分離单默，將不同的職責封裝在不同的類中，就像我們前端在開發(fā)頁面的時候忘瓦，進行頁面的組件化拆分搁廓，把顆粒度減少引颈，每個頁面組件都負責不同的工作。
demo:
從demo上可以知道People類中境蜕，承擔的太多的職責了蝙场，又要供血，又要吃東西粱年。因此應該對People這個類進行拆分售滤，People可以拆分為一下：
Heart: 負責供血，包含supplyBlood()方法
Lung: 負責呼吸台诗，包含breathe()方法
People: 負責走路和吃完箩，包含eat()和walk()
二、開閉原則
開閉原則：盡量在不修改原有代碼的情況下進行擴展功能拉队。
demo:
在該demo中弊知，如果需要增加一個新的類，如人妖 Hemophrodite粱快，則需要修改People類的say()方法的代碼秩彤，增加新的判斷邏輯，原則告訴我們要對修改關閉事哭，所以這份代碼違反了開閉原則漫雷。
可以通過抽象的方式對代碼進行重構，增加新的類時無須修改源代碼鳍咱，滿足開閉原則降盹。做法如下：
增加一個抽象人類AbstractPeople，將各種具體的人類作為子類流炕。
PeopleSay針對抽象人類進行編程澎现，由客戶端來進行做哪一類人。
若此時需要用一個人要每辟，僅需擴展一個 Hemophrodite 類剑辫，將 Hemophrodite 也作為 AbstractPeople 的子類即可，且無需修改其他代碼渠欺。這種對擴展開放妹蔽，對修改封閉就是屬于開閉原則。
demo:
三挠将、里氏代換原則
里氏代換原則：所有引用基類（父類）的地方必須能透明地使用其子類的對象胳岂。
里氏代換原則告訴我們，在軟件中將一個基類對象替換成它的子類對象舔稀，程序將不會產生任何錯誤和異常乳丰，反過來則不成立，如果一個軟件實體使用的是一個子類對象的話内贮，那么它不一定能夠使用基類對象产园。例如：我喜歡人汞斧，那我一定喜歡女人，因為女人是人的子類什燕；但是我喜歡女人粘勒，不能據此斷定我喜歡人，因為我并不喜歡人妖或者男人屎即，雖然他們也是人庙睡。
四、依賴倒轉原則
依賴倒轉原則：抽象不應該依賴于細節(jié)技俐，細節(jié)應當依賴于抽象乘陪。換言之，要針對接口編程虽另，而不是針對實現編程暂刘。簡單來說，設計代碼之前捂刺，先不要考慮什么算法之類的實現功能谣拣，應該注重怎么利用類和方法來描述好功能的實現。
五族展、隔離原則
接口隔離原則：使用多個專門的接口森缠，而不使用單一的總接口，即客戶端不應該依賴那些它不需要的接口仪缸。
這個原則的意思是：使用多個隔離的接口贵涵，比使用單個接口要好。它還有另一個意思是：降低類之間的耦合度恰画。由此可見宾茂，其實設計模式就是從大型軟件架構出發(fā)、便于升級和維護的軟件設計思想拴还，它強調降低依賴跨晴，降低耦合。
六片林、合成復用原則
合成復用原則：盡量使用對象組合端盆，而不是繼承來達到復用的目的。
七费封、迪米特法則
迪米特法則：一個軟件實體應當盡可能少地與其他實體發(fā)生相互作用焕妙。
如果一個系統(tǒng)符合迪米特法則，那么當其中某一個模塊發(fā)生修改時弓摘，就會盡量少地影響其他模塊焚鹊，擴展會相對容易。迪米特法則可降低系統(tǒng)的耦合度韧献，使類與類之間保持松散的耦合關系末患。
