設(shè)計(jì)中各各原則同時兼有或沖突，不存在包含所有原則的設(shè)計(jì)

一：單一職責(zé)原則又稱單一功能原則

核心：解耦和增強(qiáng)內(nèi)聚性（高內(nèi)聚，低耦合）

描述：類被修改的幾率很大，因此應(yīng)該專注于單一的功能。如果你把多個功能放在同一個類中，功能之間就形成了關(guān)聯(lián)。

二：開閉原則

核心：用抽象構(gòu)建框架，用實(shí)現(xiàn)類實(shí)現(xiàn)擴(kuò)展。

描述：不允許更改系統(tǒng)的抽象層，而允許擴(kuò)展的是系統(tǒng)的實(shí)現(xiàn)層。

抽象抓住最重要的東西，從更高一層思考。這降低了思考的復(fù)雜度，不用同時考慮那么多。封裝事物的本質(zhì)，看不到任何細(xì)節(jié)。

三：里氏替換原則

核心：在任何父類出現(xiàn)的地方都可以用他的子類來替代。

描述：當(dāng)把這個基類替換成繼承該基類的子類，程序的行為不會發(fā)生任何變化。軟件實(shí)體察覺不出基類對象和子類對象的區(qū)別?？梢院苋菀椎膶?shí)現(xiàn)同一父類下各個子類的互換，而客戶端可以毫不察覺。

四：依賴倒轉(zhuǎn)原則

核心：要依賴于抽象，不要依賴于具體的實(shí)現(xiàn)

描述：高層模塊不應(yīng)該依賴低層模塊，兩者都應(yīng)該依賴其抽象（抽象類或接口），抽象不應(yīng)該依賴細(xì)節(jié)（具體實(shí)現(xiàn)），細(xì)節(jié)（具體實(shí)現(xiàn)）應(yīng)該依賴抽象。

五：接口分離原則

核心：不應(yīng)該強(qiáng)迫客戶程序依賴他們不需要使用的方法。

描述：使用多個專一功能的接口比使用一個的總接口總要好。

六：合成復(fù)用原則

核心：組合（或聚合）大于繼承。

描述：新對象的某些功能在別的已經(jīng)創(chuàng)建好的對象里面已經(jīng)實(shí)現(xiàn)，那么使用別的對象提供的功能，使之成為新對象的一部分，而不要自己再重新創(chuàng)建。新對象通過向這些對象的委派達(dá)到復(fù)用已有功能的。

七：迪米特原則

核心：一個對象應(yīng)當(dāng)對其他對象有盡可能少的了解。

描述：類間解耦，低耦合）意思就是降低各個對象之間的耦合，提高系統(tǒng)的可維護(hù)性；在模塊之間只通過接口來通信，而不理會模塊的內(nèi)部工作原理，可以使各個模塊的耦合成都降到最低，促進(jìn)軟件的復(fù)用。

常用模式說明

說明：所謂設(shè)計(jì)模式，不過是前人的經(jīng)驗(yàn)之談，不可強(qiáng)行使用解決問題，也要避免模式病（什么問題都要用模式解決）

工廠模式

意圖：定義一個創(chuàng)建對象的接口，讓其子類自己決定實(shí)例化哪一個工廠類，工廠模式使其創(chuàng)建過程延遲到子類進(jìn)行。

主要解決：主要解決接口選擇的問題。

何時使用：我們明確地計(jì)劃不同條件下創(chuàng)建不同實(shí)例時。

抽象工廠模式

意圖：提供一個創(chuàng)建一系列相關(guān)或相互依賴對象的接口，而無需指定它們具體的類。

主要解決：主要解決接口選擇的問題。

何時使用：系統(tǒng)的產(chǎn)品有多于一個的產(chǎn)品族，而系統(tǒng)只消費(fèi)其中某一族的產(chǎn)品。

單例模式

意圖：保證一個類僅有一個實(shí)例，并提供一個訪問它的全局訪問點(diǎn)。

主要解決：一個全局使用的類頻繁地創(chuàng)建與銷毀。

何時使用：當(dāng)您想控制實(shí)例數(shù)目，節(jié)省系統(tǒng)資源的時候。

建造者模式

意圖：將一個復(fù)雜的構(gòu)建與其表示相分離，使得同樣的構(gòu)建過程可以創(chuàng)建不同的表示。

主要解決：主要解決在軟件系統(tǒng)中，有時候面臨著"一個復(fù)雜對象"的創(chuàng)建工作，其通常由各個部分的子對象用一定的算法構(gòu)成；由于需求的變化，這個復(fù)雜對象的各個部分經(jīng)常面臨著劇烈的變化，但是將它們組合在一起的算法卻相對穩(wěn)定。

何時使用：一些基本部件不會變，而其組合經(jīng)常變化的時候。

原型模式

意圖：用原型實(shí)例指定創(chuàng)建對象的種類，并且通過拷貝這些原型創(chuàng)建新的對象。

主要解決：在運(yùn)行期建立和刪除原型。

何時使用： 1、當(dāng)一個系統(tǒng)應(yīng)該獨(dú)立于它的產(chǎn)品創(chuàng)建，構(gòu)成和表示時。 2、當(dāng)要實(shí)例化的類是在運(yùn)行時刻指定時，例如，通過動態(tài)裝載。 3、為了避免創(chuàng)建一個與產(chǎn)品類層次平行的工廠類層次時。 4、當(dāng)一個類的實(shí)例只能有幾個不同狀態(tài)組合中的一種時。建立相應(yīng)數(shù)目的原型并克隆它們可能比每次用合適的狀態(tài)手工實(shí)例化該類更方便一些。

適配器模式

意圖：將一個類的接口轉(zhuǎn)換成客戶希望的另外一個接口。使原本由于接口不兼容而不能一起工作的那些類可以一起工作。

主要解決：主要解決在軟件系統(tǒng)中，常常要將一些"現(xiàn)存的對象"放到新的環(huán)境中，新環(huán)境要求的接口是現(xiàn)對象不能滿足的。

何時使用： 1、系統(tǒng)需要使用現(xiàn)有的類，而此類的接口不符合系統(tǒng)的需要。 2、想要建立一個可以重復(fù)使用的類，用于與一些彼此之間沒有太大關(guān)聯(lián)的一些類，包括一些可能在將來引進(jìn)的類一起工作，這些源類不一定有一致的接口。 3、通過接口轉(zhuǎn)換，將一個類插入另一個類系中。（比如老虎和飛禽，現(xiàn)在多了一個飛虎，在不增加實(shí)體的需求下，增加一個適配器，在里面包容一個虎對象，實(shí)現(xiàn)飛的接口。）

組合模式

意圖：將對象組合成樹形結(jié)構(gòu)以表示"部分-整體"的層次結(jié)構(gòu)。組合模式使得用戶對單個對象和組合對象的使用具有一致性。

主要解決：它在我們樹型結(jié)構(gòu)的問題中，模糊了簡單元素和復(fù)雜元素的概念，客戶程序可以向處理簡單元素一樣來處理復(fù)雜元素，從而使得客戶程序與復(fù)雜元素的內(nèi)部結(jié)構(gòu)解耦。

何時使用： 1、您想表示對象的部分-整體層次結(jié)構(gòu)（樹形結(jié)構(gòu)）。 2、您希望用戶忽略組合對象與單個對象的不同，用戶將統(tǒng)一地使用組合結(jié)構(gòu)中的所有對象。

裝飾器模式

意圖：動態(tài)地給一個對象添加一些額外的職責(zé)。就增加功能來說，裝飾器模式相比生成子類更為靈活。

主要解決：為了擴(kuò)展一個類經(jīng)常使用繼承方式實(shí)現(xiàn)，由于繼承為類引入靜態(tài)特征，并且隨著擴(kuò)展功能的增多，子類會很膨脹。

何時使用：在不想增加很多子類的情況下擴(kuò)展類。

外觀模式

意圖：為子系統(tǒng)中的一組接口提供一個一致的界面，外觀模式定義了一個高層接口，這個接口使得這一子系統(tǒng)更加容易使用。

主要解決：降低訪問復(fù)雜系統(tǒng)的內(nèi)部子系統(tǒng)時的復(fù)雜度，簡化客戶端與之的接口。

何時使用： 1、客戶端不需要知道系統(tǒng)內(nèi)部的復(fù)雜聯(lián)系，整個系統(tǒng)只需提供一個"接待員"即可。 2、定義系統(tǒng)的入口

享元模式

意圖：運(yùn)用共享技術(shù)有效地支持大量細(xì)粒度的對象。

主要解決：在有大量對象時，有可能會造成內(nèi)存溢出，我們把其中共同的部分抽象出來，如果有相同的業(yè)務(wù)請求，直接返回在內(nèi)存中已有的對象，避免重新創(chuàng)建。

何時使用： 1、系統(tǒng)中有大量對象。 2、這些對象消耗大量內(nèi)存。 3、這些對象的狀態(tài)大部分可以外部化。 4、這些對象可以按照內(nèi)蘊(yùn)狀態(tài)分為很多組，當(dāng)把外蘊(yùn)對象從對象中剔除出來時，每一組對象都可以用一個對象來代替。 5、系統(tǒng)不依賴于這些對象身份，這些對象是不可分辨的。

代理模式

意圖：為其他對象提供一種代理以控制對這個對象的訪問。

主要解決：在直接訪問對象時帶來的問題，比如說：要訪問的對象在遠(yuǎn)程的機(jī)器上。在面向?qū)ο笙到y(tǒng)中，有些對象由于某些原因（比如對象創(chuàng)建開銷很大，或者某些操作需要安全控制，或者需要進(jìn)程外的訪問），直接訪問會給使用者或者系統(tǒng)結(jié)構(gòu)帶來很多麻煩，我們可以在訪問此對象時加上一個對此對象的訪問層。

何時使用：想在訪問一個類時做一些控制。

責(zé)任鏈模式

意圖：避免請求發(fā)送者與接收者耦合在一起，讓多個對象都有可能接收請求，將這些對象連接成一條鏈，并且沿著這條鏈傳遞請求，直到有對象處理它為止。

主要解決：職責(zé)鏈上的處理者負(fù)責(zé)處理請求，客戶只需要將請求發(fā)送到職責(zé)鏈上即可，無須關(guān)心請求的處理細(xì)節(jié)和請求的傳遞，所以職責(zé)鏈將請求的發(fā)送者和請求的處理者解耦了。

命令模式

意圖：將一個請求封裝成一個對象，從而使您可以用不同的請求對客戶進(jìn)行參數(shù)化。

主要解決：在軟件系統(tǒng)中，行為請求者與行為實(shí)現(xiàn)者通常是一種緊耦合的關(guān)系，但某些場合，比如需要對行為進(jìn)行記錄、撤銷或重做、事務(wù)等處理時，這種無法抵御變化的緊耦合的設(shè)計(jì)就不太合適。

何時使用：在某些場合，比如要對行為進(jìn)行"記錄、撤銷/重做、事務(wù)"等處理，這種無法抵御變化的緊耦合是不合適的。在這種情況下，如何將"行為請求者"與"行為實(shí)現(xiàn)者"解耦？將一組行為抽象為對象，可以實(shí)現(xiàn)二者之間的松耦合。

中介者模式

意圖：用一個中介對象來封裝一系列的對象交互，中介者使各對象不需要顯式地相互引用，從而使其耦合松散，而且可以獨(dú)立地改變它們之間的交互。

主要解決：對象與對象之間存在大量的關(guān)聯(lián)關(guān)系，這樣勢必會導(dǎo)致系統(tǒng)的結(jié)構(gòu)變得很復(fù)雜，同時若一個對象發(fā)生改變，我們也需要跟蹤與之相關(guān)聯(lián)的對象，同時做出相應(yīng)的處理。

何時使用：多個類相互耦合，形成了網(wǎng)狀結(jié)構(gòu)。

觀察者模式

意圖：定義對象間的一種一對多的依賴關(guān)系，當(dāng)一個對象的狀態(tài)發(fā)生改變時，所有依賴于它的對象都得到通知并被自動更新。

主要解決：一個對象狀態(tài)改變給其他對象通知的問題，而且要考慮到易用和低耦合，保證高度的協(xié)作。

何時使用：一個對象（目標(biāo)對象）的狀態(tài)發(fā)生改變，所有的依賴對象（觀察者對象）都將得到通知，進(jìn)行廣播通知。

狀態(tài)模式

意圖：允許對象在內(nèi)部狀態(tài)發(fā)生改變時改變它的行為，對象看起來好像修改了它的類。

主要解決：對象的行為依賴于它的狀態(tài)（屬性），并且可以根據(jù)它的狀態(tài)改變而改變它的相關(guān)行為。

何時使用：代碼中包含大量與對象狀態(tài)有關(guān)的條件語句。

策略模式

意圖：定義一系列的算法,把它們一個個封裝起來, 并且使它們可相互替換。

主要解決：在有多種算法相似的情況下，使用 if...else 所帶來的復(fù)雜和難以維護(hù)。

何時使用：一個系統(tǒng)有許多許多類，而區(qū)分它們的只是他們直接的行為。

模板模式

意圖：定義一個操作中的算法的骨架，而將一些步驟延遲到子類中。模板方法使得子類可以不改變一個算法的結(jié)構(gòu)即可重定義該算法的某些特定步驟。

主要解決：一些方法通用，卻在每一個子類都重新寫了這一方法。

何時使用：有一些通用的方法。

不常用模式

橋接模式，過濾器模式，解釋器模式，迭代器模式，備忘錄模式，空對象模式，訪問者模式

如若轉(zhuǎn)載，請注明出處：開源字節(jié) ? https://sourcebyte.vip/article/323.html