怎樣寫出好代碼——設計原則

1. 單一職責原則（Single Responsibility Principle - SRP）

原文：

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

譯文：

永遠不該該有多於一個緣由來改變某個類。

理解：

對於一個類而言，應該僅有一個引發它變化的緣由。說白了就是，不一樣的類具有不一樣的職責，各施其責。這就比如一個團隊，你們分工協做，互不影響，各作各的事情。

應用：

當咱們作系統設計時，若是發現有一個類擁有了兩種的職責，那就問本身一個問題：能夠將這個類分紅兩個類嗎？若是真的有必要，那就分吧。千萬不要讓一個類乾的事情太多！

2. 開放封閉原則（Open Closed Principle - OCP）

原文：

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

譯文：

軟件實體，如：類、模塊與函數，對於擴展應該是開放的，但對於修改應該是封閉的。

理解：

簡言之，對擴展開放，對修改封閉。換句話說，能夠去擴展類，但不要去修改類。

應用：

當需求有改動，要修改代碼了，此時您要作的是，儘可能用繼承或組合的方式來擴展類的功能，而不是直接修改類的代碼。固然，若是可以確保對總體架構不會產生任何影響，那麼也不必搞得那麼複雜了，直接改這個類吧。

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.

譯文：

使用基類的指針或引用的函數，必須是在不知情的狀況下，可以使用派生類的對象。

理解：

父類可以替換子類，但子類不必定能替換父類。也就是說，在代碼中能夠將父類所有替換爲子類，程序不會報錯，也不會在運行時出現任何異常，但反過來卻不必定成立。

應用：

在繼承類時，務必重寫（Override）父類中全部的方法，尤爲須要注意父類的 protected 方法（它們每每是讓您重寫的），子類儘可能不要暴露本身的 public 方法供外界調用。

4. 最少知識原則（Least Knowledge Principle - LKP）

原文：

Only talk to you immediate friends.

譯文：

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

理解：

儘可能減小對象之間的交互，從而減少類之間的耦合。簡言之，必定要作到：低耦合，高內聚。

應用：

在作系統設計時，不要讓一個類依賴於太多的其餘類，需儘可能減少依賴關係，不然，您死都不知道本身怎麼死的。

該原則也稱爲「迪米特法則（Law of Demeter）」，由 Ian Holland 提出。

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

原文：

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

譯文：

一個類與另外一個類之間的依賴性，應該依賴於儘量小的接口。

理解：

不要對外暴露沒有實際意義的接口。也就是說，接口是給別人調用的，那就不要去爲難別人了，儘量保證接口的實用性吧。

應用：

當須要對外暴露接口時，須要再三斟酌，若是真的沒有必要對外提供的，就刪了吧。一旦您提供了，就意味着，您未來要多作一件事情，何苦要給本身找事作呢。

1. 依賴倒置原則（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.

譯文：

高層模塊不該該依賴於低層模塊，它們應該依賴於抽象。抽象不該該依賴於細節，細節應該依賴於抽象。

理解：

應該面向接口編程，不該該面向實現類編程。面向實現類編程，至關於就是論事，那是正向依賴（正常人思惟）；面向接口編程，至關於經過事物表象來看本質，那是反向依賴，即依賴倒置（程序員思惟）。

應用：

並非說，全部的類都要有一個對應的接口，而是說，若是有接口，那就儘可能使用接口來編程吧。

將以上六大原則的英文首字母拼在一塊兒就是 SOLID（穩定的），因此也稱之爲 SOLID 原則。

2、補充設計原則

1. 組合/聚合複用原則（Composition/Aggregation Reuse Principle - CARP）

當要擴展類的功能時，優先考慮使用組合，而不是繼承。這條原則在 23 種經典設計模式中頻繁使用，如：代理模式、裝飾模式、適配器模式等。可見江湖地位很是之高！

2. 無環依賴原則（Acyclic Dependencies Principle - ADP）

當 A 模塊依賴於 B 模塊，B 模塊依賴於 C 模塊，C 依賴於 A 模塊，此時將出現循環依賴。在設計中應該避免這個問題，可經過引入「中介者模式」解決該問題。

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

應該將易變的類放在同一個包裏，將變化隔離出來。該原則是「開放-封閉原則」的延生。

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

若是重用了包中的一個類，那麼也就至關於重用了包中的全部類，咱們要儘量減少包的大小。

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

好萊塢明星的經紀人通常都很忙，他們不想被打擾，每每會說：Don't call me, I'll call you. 翻譯爲：不要聯繫我，我會聯繫你。對應於軟件設計而言，最著名的就是「控制反轉」（或稱爲「依賴注入」），咱們不須要在代碼中主動的建立對象，而是由容器幫咱們來建立並管理這些對象。

3、其餘設計原則

1. 不要重複你本身（Don't repeat yourself - DRY）

不要讓重複的代碼處處都是，要讓它們足夠的重用，因此要儘量地封裝。

2. 保持它簡單與傻瓜（Keep it simple and stupid - KISS）

不要讓系統變得複雜，界面簡潔，功能實用，操做方便，要讓它足夠的簡單，足夠的傻瓜。

3. 高內聚與低耦合（High Cohesion and Low Coupling - HCLC）

模塊內部須要作到內聚度高，模塊之間須要作到耦合度低。

4. 慣例優於配置（Convention over Configuration - COC）

儘可能讓慣例來減小配置，這樣才能提升開發效率，儘可能作到「零配置」。不少開發框架都是這樣作的。

5. 命令查詢分離（Command Query Separation - CQS）

在定義接口時，要作到哪些是命令，哪些是查詢，要將它們分離，而不要揉到一塊兒。

6. 關注點分離（Separation of Concerns - SOC）

將一個複雜的問題分離爲多個簡單的問題，而後逐個解決這些簡單的問題，那麼這個複雜的問題就解決了。難就難在如何進行分離。

7. 契約式設計（Design by Contract - DBC）

模塊或系統之間的交互，都是基於契約（接口或抽象）的，而不要依賴於具體實現。該原則建議咱們要面向契約編程。

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

不要一開始就把系統設計得很是複雜，不要陷入「過分設計」的深淵。應該讓系統足夠的簡單，而卻又不失擴展性，這是其中的難點。