1. 程式人生 > >軟體設計原則

軟體設計原則

設計原則的重要性是這樣的:

設計原則>設計模式>資料結構和演算法>架構設計

對於Java開發者來說,重要性是這樣的:

設計原則>設計模式>Java基礎>Java高階特性>JVM虛擬機器>netty>Spring、Mybatis>Redis>MQ>zookeeper>dubbo>架構

越前面的代表越基礎

一、六大設計原則

先看一幅圖吧:

這幅圖清晰地表達了六大設計原則,但僅限於它們叫什麼名字而已,它們具體是什麼意思呢?下面我將從原文、譯文、理解、應用,這四個方面分別進行闡述。

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 方法供外界呼叫。

該原則由麻省理工學院的 Barbara Liskov 女士提出,她是美國第一位獲取計算機博士學位的女性,曾經也獲得過計算機圖靈獎。

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.

譯文:

一個類與另一個類之間的依賴性,應該依賴於儘可能小的介面。

理解:

不要對外暴露沒有實際意義的介面。也就是說,介面是給別人呼叫的,那就不要去為難別人了,儘可能保證介面的實用性吧。她好,我也好。

應用:

當需要對外暴露介面時,需要再三斟酌,如果真的沒有必要對外提供的,就刪了吧。一旦您提供了,就意味著,您將來要多做一件事情,何苦要給自己找事做呢。

6. 依賴倒置原則(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 原則。

只有滿足了這六大原則,才能設計出穩定的軟體架構!但它們畢竟只是原則,只是四人幫給我們的建議,有些時候我們還是要學會靈活應變,千萬不要生搬硬套,否則只會把簡單問題複雜化,切記!

二、補充設計原則

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. 翻譯為:不要聯絡我,我會聯絡你。對應於軟體設計而言,最著名的就是“控制反轉”(或稱為“依賴注入”),我們不需要在程式碼中主動的建立物件,而是由容器幫我們來建立並管理這些物件。

三、其他設計原則

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)

不要一開始就把系統設計得非常複雜,不要陷入“過度設計”的深淵。應該讓系統足夠的簡單,而卻又不失擴充套件性,這是其中的難點。