1. 單一職責(zé)原則（Single Responsibility Principle - SRP）

原文：There should never be more than one reason for a class to change.

譯文：永遠(yuǎn)不應(yīng)該有多于一個(gè)原因來(lái)改變某個(gè)類(lèi)。

理解：對(duì)于一個(gè)類(lèi)而言，應(yīng)該僅有一個(gè)引起它變化的原因。說(shuō)白了就是，不同的類(lèi)具備不同的職責(zé)，各施其責(zé)。這就好比一個(gè)團(tuán)隊(duì)，大家分工協(xié)作，互不影響，各做各的事情。

應(yīng)用：當(dāng)我們做系統(tǒng)設(shè)計(jì)時(shí)，如果發(fā)現(xiàn)有一個(gè)類(lèi)擁有了兩種的職責(zé)，那就問(wèn)自己一個(gè)問(wèn)題：可以將這個(gè)類(lèi)分成兩個(gè)類(lèi)嗎？如果真的有必要，那就分吧。千萬(wàn)不要讓一個(gè)類(lèi)干的事情太多！

2. 開(kāi)放封閉原則（Open Closed Principle - OCP）

原文：Software entities like classes, modules and functions should be open for extension but closed for modifications.

譯文：軟件實(shí)體，如：類(lèi)、模塊與函數(shù)，對(duì)于擴(kuò)展應(yīng)該是開(kāi)放的，但對(duì)于修改應(yīng)該是封閉的。

理解：簡(jiǎn)言之，對(duì)擴(kuò)展開(kāi)放，對(duì)修改封閉。換句話(huà)說(shuō)，可以去擴(kuò)展類(lèi)，但不要去修改類(lèi)。

應(yīng)用：當(dāng)需求有改動(dòng)，要修改代碼了，此時(shí)您要做的是，盡量用繼承或組合的方式來(lái)擴(kuò)展類(lèi)的功能，而不是直接修改類(lèi)的代碼。當(dāng)然，如果能夠確保對(duì)整體架構(gòu)不會(huì)產(chǎn)生任何影響，那么也沒(méi)必要搞得那么復(fù)雜了，直接改這個(gè)類(lèi)吧。

3. 里氏替換原則（Liskov Substitution Principle - LSP）

原文：Functions that use pointers or references to base classes must be able to use objects of derived classes without knowing it.

譯文：使用基類(lèi)的指針或引用的函數(shù)，必須是在不知情的情況下，能夠使用派生類(lèi)的對(duì)象。

理解：父類(lèi)能夠替換子類(lèi)，但子類(lèi)不一定能替換父類(lèi)。也就是說(shuō)，在代碼中可以將父類(lèi)全部替換為子類(lèi)，程序不會(huì)報(bào)錯(cuò)，也不會(huì)在運(yùn)行時(shí)出現(xiàn)任何異常，但反過(guò)來(lái)卻不一定成立。

應(yīng)用：在繼承類(lèi)時(shí)，務(wù)必重寫(xiě)（Override）父類(lèi)中所有的方法，尤其需要注意父類(lèi)的 protected 方法（它們往往是讓您重寫(xiě)的），子類(lèi)盡量不要暴露自己的 public 方法供外界調(diào)用。

4. 最少知識(shí)原則（Least Knowledge Principle - LKP）

原文：Only talk to you immediate friends.

譯文：只與你最直接的朋友交流。

理解：盡量減少對(duì)象之間的交互，從而減小類(lèi)之間的耦合。簡(jiǎn)言之，一定要做到：低耦合，高內(nèi)聚。

應(yīng)用：在做系統(tǒng)設(shè)計(jì)時(shí)，不要讓一個(gè)類(lèi)依賴(lài)于太多的其他類(lèi)，需盡量減小依賴(lài)關(guān)系，否則，您死都不知道自己怎么死的。

5. 接口隔離原則（Interface Segregation Principle - ISP）

原文：The dependency of one class to another one should depend on the smallest possible interface.

譯文：一個(gè)類(lèi)與另一個(gè)類(lèi)之間的依賴(lài)性，應(yīng)該依賴(lài)于盡可能小的接口。

理解：不要對(duì)外暴露沒(méi)有實(shí)際意義的接口。也就是說(shuō)，接口是給別人調(diào)用的，那就不要去為難別人了，盡可能保證接口的實(shí)用性吧。她好，我也好。

應(yīng)用：當(dāng)需要對(duì)外暴露接口時(shí)，需要再三斟酌，如果真的沒(méi)有必要對(duì)外提供的，就刪了吧。一旦您提供了，就意味著，您將來(lái)要多做一件事情，何苦要給自己找事做呢。

6. 依賴(lài)倒置原則（Dependence Inversion Principle - DIP）

原文：High level modules should not depends upon low level modules. Both should depend upon abstractions. Abstractions should not depend upon details. Details should depend upon abstractions.

譯文：高層模塊不應(yīng)該依賴(lài)于低層模塊，它們應(yīng)該依賴(lài)于抽象。抽象不應(yīng)該依賴(lài)于細(xì)節(jié)，細(xì)節(jié)應(yīng)該依賴(lài)于抽象。

理解：應(yīng)該面向接口編程，不應(yīng)該面向?qū)崿F(xiàn)類(lèi)編程。面向?qū)崿F(xiàn)類(lèi)編程，相當(dāng)于就是論事，那是正向依賴(lài)（正常人思維）；面向接口編程，相當(dāng)于通過(guò)事物表象來(lái)看本質(zhì)，那是反向依賴(lài)，即依賴(lài)倒置（程序員思維）。

應(yīng)用：并不是說(shuō)，所有的類(lèi)都要有一個(gè)對(duì)應(yīng)的接口，而是說(shuō)，如果有接口，那就盡量使用接口來(lái)編程吧。

將以上六大原則的英文首字母拼在一起就是 SOLID（穩(wěn)定的），所以也稱(chēng)之為 SOLID 原則。只有滿(mǎn)足了這六大原則，才能設(shè)計(jì)出穩(wěn)定的軟件架構(gòu)！但它們畢竟只是原則，只是四人幫給我們的建議，有些時(shí)候我們還是要學(xué)會(huì)靈活應(yīng)變，千萬(wàn)不要生搬硬套，否則只會(huì)把簡(jiǎn)單問(wèn)題復(fù)雜化

補(bǔ)充設(shè)計(jì)原則

1. 組合/聚合復(fù)用原則（Composition/Aggregation Reuse Principle - CARP）

當(dāng)要擴(kuò)展類(lèi)的功能時(shí)，優(yōu)先考慮使用組合，而不是繼承。這條原則在 23 種經(jīng)典設(shè)計(jì)模式中頻繁使用，如：代理模式、裝飾模式、適配器模式等?？梢?jiàn)江湖地位非常之高！

2. 無(wú)環(huán)依賴(lài)原則（Acyclic Dependencies Principle - ADP）

當(dāng) A 模塊依賴(lài)于 B 模塊，B 模塊依賴(lài)于 C 模塊，C 依賴(lài)于 A 模塊，此時(shí)將出現(xiàn)循環(huán)依賴(lài)。在設(shè)計(jì)中應(yīng)該避免這個(gè)問(wèn)題，可通過(guò)引入“中介者模式”解決該問(wèn)題。

3. 共同封裝原則（Common Closure Principle - CCP）

應(yīng)該將易變的類(lèi)放在同一個(gè)包里，將變化隔離出來(lái)。該原則是“開(kāi)放-封閉原則”的延生。

4. 共同重用原則（Common Reuse Principle - CRP）

如果重用了包中的一個(gè)類(lèi)，那么也就相當(dāng)于重用了包中的所有類(lèi)，我們要盡可能減小包的大小。

5. 好萊塢原則（Hollywood Principle - HP）

好萊塢明星的經(jīng)紀(jì)人一般都很忙，他們不想被打擾，往往會(huì)說(shuō)：Don't call me, I'll call you. 翻譯為：不要聯(lián)系我，我會(huì)聯(lián)系你。對(duì)應(yīng)于軟件設(shè)計(jì)而言，最著名的就是“控制反轉(zhuǎn)”（或稱(chēng)為“依賴(lài)注入”），我們不需要在代碼中主動(dòng)的創(chuàng)建對(duì)象，而是由容器幫我們來(lái)創(chuàng)建并管理這些對(duì)象。

其它設(shè)計(jì)原則

1. 不要重復(fù)你自己（Don't repeat yourself - DRY）

不要讓重復(fù)的代碼到處都是，要讓它們足夠的重用，所以要盡可能地封裝。

2. 保持它簡(jiǎn)單與傻瓜（Keep it simple and stupid - KISS）

不要讓系統(tǒng)變得復(fù)雜，界面簡(jiǎn)潔，功能實(shí)用，操作方便，要讓它足夠的簡(jiǎn)單，足夠的傻瓜。

3. 高內(nèi)聚與低耦合（High Cohesion and Low Coupling - HCLC）

模塊內(nèi)部需要做到內(nèi)聚度高，模塊之間需要做到耦合度低。

4. 慣例優(yōu)于配置（Convention over Configuration - COC）

盡量讓?xiě)T例來(lái)減少配置，這樣才能提高開(kāi)發(fā)效率，盡量做到“零配置”。很多開(kāi)發(fā)框架都是這樣做的。

5. 命令查詢(xún)分離（Command Query Separation - CQS）

在定義接口時(shí)，要做到哪些是命令，哪些是查詢(xún)，要將它們分離，而不要揉到一起。

6. 關(guān)注點(diǎn)分離（Separation of Concerns - SOC）

將一個(gè)復(fù)雜的問(wèn)題分離為多個(gè)簡(jiǎn)單的問(wèn)題，然后逐個(gè)解決這些簡(jiǎn)單的問(wèn)題，那么這個(gè)復(fù)雜的問(wèn)題就解決了。難就難在如何進(jìn)行分離。

7. 契約式設(shè)計(jì)（Design by Contract - DBC）

模塊或系統(tǒng)之間的交互，都是基于契約（接口或抽象）的，而不要依賴(lài)于具體實(shí)現(xiàn)。該原則建議我們要面向契約編程。

8. 你不需要它（You aren't gonna need it - YAGNI）

不要一開(kāi)始就把系統(tǒng)設(shè)計(jì)得非常復(fù)雜，不要陷入“過(guò)度設(shè)計(jì)”的深淵。應(yīng)該讓系統(tǒng)足夠的簡(jiǎn)單，而卻又不失擴(kuò)展性，這是其中的難點(diǎn)。

出處：http://blog.csdn.net/u012562943/article/details/76110761