1. 單一職責(zé)原則(SRP)

定義：就一個(gè)類(lèi)而言，應(yīng)該僅有一個(gè)引起它變化的原因。

從這句定義我們很難理解它的含義，通俗講就是我們不要讓一個(gè)類(lèi)承擔(dān)過(guò)多的職責(zé)。如果一個(gè)類(lèi)承擔(dān)的職責(zé)過(guò)多，就等于把這些職責(zé)耦合在一起，一個(gè)職責(zé)的變化可能會(huì)削弱或者抑制這個(gè)類(lèi)完成其他職責(zé)的能力。這種耦合會(huì)導(dǎo)致脆弱的設(shè)計(jì)，當(dāng)變化發(fā)生時(shí)，設(shè)計(jì)會(huì)遭受到破壞。

比如我經(jīng)?？吹揭恍〢ndroid開(kāi)發(fā)在Activity中寫(xiě)B(tài)ean文件，網(wǎng)絡(luò)數(shù)據(jù)處理，如果有列表的話(huà)Adapter 也寫(xiě)在Activity中，問(wèn)他們?yōu)槭裁闯撕谜乙矝](méi)啥理由了，把他們拆分到其他類(lèi)豈不是更好找，如果Activity過(guò)于臃腫行數(shù)過(guò)多，顯然不是好事，如果我們要修改Bean文件，網(wǎng)絡(luò)處理和Adapter都需要上這個(gè)Activity來(lái)修改，就會(huì)導(dǎo)致引起這個(gè)Activity變化的原因太多，我們?cè)诎姹揪S護(hù)時(shí)也會(huì)比較頭疼。也就嚴(yán)重違背了定義“就一個(gè)類(lèi)而言，應(yīng)該僅有一個(gè)引起它變化的原因”。

當(dāng)然如果想爭(zhēng)論的話(huà)，這個(gè)模式是可以引起很多爭(zhēng)論的，但請(qǐng)記住一點(diǎn)，你寫(xiě)代碼不只是為了你也是為了其他人。

2. 開(kāi)放封閉原則(ASD)

定義：類(lèi)、模塊、函數(shù)等等等應(yīng)該是可以拓展的，但是不可修改。

開(kāi)放封閉有兩個(gè)含義，一個(gè)是對(duì)于拓展是開(kāi)放的，另一個(gè)是對(duì)于修改是封閉的。對(duì)于開(kāi)發(fā)來(lái)說(shuō)需求肯定是要變化的，但是新需求一來(lái)，我們就要把類(lèi)重新改一遍這顯然是令人頭疼的，所以我們?cè)O(shè)計(jì)程序時(shí)面對(duì)需求的改變要盡可能的保證相對(duì)的穩(wěn)定，盡量用新代碼實(shí)現(xiàn)拓展來(lái)修改需求，而不是通過(guò)修改原有的代碼來(lái)實(shí)現(xiàn)。

假設(shè)我們要實(shí)現(xiàn)一個(gè)列表，一開(kāi)始只有查詢(xún)的功能，如果產(chǎn)品又要增加添加功能，過(guò)幾天又要增加刪除功能，大多數(shù)人的做法是寫(xiě)個(gè)方法然后通過(guò)傳入不同的值來(lái)控制方法來(lái)實(shí)現(xiàn)不同的功能，但是如果又要新增功能我們還得修改我們的方法。用開(kāi)發(fā)封閉原則解決就是增加一個(gè)抽象的功能類(lèi)，讓增加和刪除和查詢(xún)的作為這個(gè)抽象功能類(lèi)的子類(lèi)，這樣如果我們?cè)偬砑庸δ埽銜?huì)發(fā)現(xiàn)我們不需要修改原有的類(lèi)，只需要添加一個(gè)功能類(lèi)的子類(lèi)實(shí)現(xiàn)功能類(lèi)的方法就可以了。

3.里氏替換原則(LSP)

定義：所有引用基類(lèi)（父類(lèi)）的地方必須能透明地使用其子類(lèi)的對(duì)象

里氏代換原則告訴我們，在軟件中將一個(gè)基類(lèi)對(duì)象替換成它的子類(lèi)對(duì)象，程序?qū)⒉粫?huì)產(chǎn)生任何錯(cuò)誤和異常，反過(guò)來(lái)則不成立，如果一個(gè)軟件實(shí)體使用的是一個(gè)子類(lèi)對(duì)象的話(huà)，那么它不一定能夠使用基類(lèi)對(duì)象。

里氏代換原則是實(shí)現(xiàn)開(kāi)閉原則的重要方式之一，由于使用基類(lèi)對(duì)象的地方都可以使用子類(lèi)對(duì)象，因此在程序中盡量使用基類(lèi)類(lèi)型來(lái)對(duì)對(duì)象進(jìn)行定義，而在運(yùn)行時(shí)再確定其子類(lèi)類(lèi)型，用子類(lèi)對(duì)象來(lái)替換父類(lèi)對(duì)象。

在使用里氏代換原則時(shí)需要注意如下幾個(gè)問(wèn)題：

子類(lèi)的所有方法必須在父類(lèi)中聲明，或子類(lèi)必須實(shí)現(xiàn)父類(lèi)中聲明的所有方法。根據(jù)里氏代換原則，為了保證系統(tǒng)的擴(kuò)展性，在程序中通常使用父類(lèi)來(lái)進(jìn)行定義，如果一個(gè)方法只存在子類(lèi)中，在父類(lèi)中不提供相應(yīng)的聲明，則無(wú)法在以父類(lèi)定義的對(duì)象中使用該方法。

我們?cè)谶\(yùn)用里氏代換原則時(shí)，盡量把父類(lèi)設(shè)計(jì)為抽象類(lèi)或者接口，讓子類(lèi)繼承父類(lèi)或?qū)崿F(xiàn)父接口，并實(shí)現(xiàn)在父類(lèi)中聲明的方法，運(yùn)行時(shí)，子類(lèi)實(shí)例替換父類(lèi)實(shí)例，我們可以很方便地?cái)U(kuò)展系統(tǒng)的功能，同時(shí)無(wú)須修改原有子類(lèi)的代碼，增加新的功能可以通過(guò)增加一個(gè)新的子類(lèi)來(lái)實(shí)現(xiàn)。里氏代換原則是開(kāi)閉原則的具體實(shí)現(xiàn)手段之一。

Java語(yǔ)言中，在編譯階段，Java編譯器會(huì)檢查一個(gè)程序是否符合里氏代換原則，這是一個(gè)與實(shí)現(xiàn)無(wú)關(guān)的、純語(yǔ)法意義上的檢查，但Java編譯器的檢查是有局限的。

4.依賴(lài)倒置原則(DIP)

定義：高層模塊不應(yīng)該依賴(lài)低層模塊，兩個(gè)都應(yīng)該依賴(lài)于抽象。抽象不應(yīng)該依賴(lài)于細(xì)節(jié)，細(xì)節(jié)應(yīng)該依賴(lài)于抽象。

在Java中，抽象就是指接口或者抽象類(lèi)，兩者都是不能直接被實(shí)例化的；細(xì)節(jié)就是實(shí)現(xiàn)類(lèi)，實(shí)現(xiàn)接口或者繼承抽象類(lèi)而產(chǎn)生的就是細(xì)節(jié)，也就是可以加上一個(gè)關(guān)鍵字new產(chǎn)生的對(duì)象。高層模塊就是調(diào)用端，低層模塊就是具體實(shí)現(xiàn)類(lèi)。

依賴(lài)倒置原則在Java中的表現(xiàn)就是：模塊間通過(guò)抽象發(fā)生，實(shí)現(xiàn)類(lèi)之間不發(fā)生直接依賴(lài)關(guān)系，其依賴(lài)關(guān)系是通過(guò)接口或者抽象類(lèi)產(chǎn)生的。如果類(lèi)與類(lèi)直接依賴(lài)細(xì)節(jié)，那么就會(huì)直接耦合，那么當(dāng)修改時(shí)，就會(huì)同時(shí)修改依賴(lài)者代碼，這樣限制了可擴(kuò)展性。

5.迪米特原則(LOD)

定義：一個(gè)軟件實(shí)體應(yīng)當(dāng)盡可能少地與其他實(shí)體發(fā)生相互作用。

也稱(chēng)為最少知識(shí)原則。如果一個(gè)系統(tǒng)符合迪米特法則，那么當(dāng)其中某一個(gè)模塊發(fā)生修改時(shí)，就會(huì)盡量少地影響其他模塊，擴(kuò)展會(huì)相對(duì)容易，這是對(duì)軟件實(shí)體之間通信的限制，迪米特法則要求限制軟件實(shí)體之間通信的寬度和深度。迪米特法則可降低系統(tǒng)的耦合度，使類(lèi)與類(lèi)之間保持松散的耦合關(guān)系。

迪米特法則要求我們?cè)谠O(shè)計(jì)系統(tǒng)時(shí)，應(yīng)該盡量減少對(duì)象之間的交互，如果兩個(gè)對(duì)象之間不必彼此直接通信，那么這兩個(gè)對(duì)象就不應(yīng)當(dāng)發(fā)生任何直接的相互作用，如果其中的一個(gè)對(duì)象需要調(diào)用另一個(gè)對(duì)象的某一個(gè)方法的話(huà)，可以通過(guò)第三者轉(zhuǎn)發(fā)這個(gè)調(diào)用。簡(jiǎn)言之，就是通過(guò)引入一個(gè)合理的第三者來(lái)降低現(xiàn)有對(duì)象之間的耦合度。

在將迪米特法則運(yùn)用到系統(tǒng)設(shè)計(jì)中時(shí)，要注意下面的幾點(diǎn)：在類(lèi)的劃分上，應(yīng)當(dāng)盡量創(chuàng)建松耦合的類(lèi)，類(lèi)之間的耦合度越低，就越有利于復(fù)用，一個(gè)處在松耦合中的類(lèi)一旦被修改，不會(huì)對(duì)關(guān)聯(lián)的類(lèi)造成太大波及；在類(lèi)的結(jié)構(gòu)設(shè)計(jì)上，每一個(gè)類(lèi)都應(yīng)當(dāng)盡量降低其成員變量和成員函數(shù)的訪(fǎng)問(wèn)權(quán)限；在類(lèi)的設(shè)計(jì)上，只要有可能，一個(gè)類(lèi)型應(yīng)當(dāng)設(shè)計(jì)成不變類(lèi)；在對(duì)其他類(lèi)的引用上，一個(gè)對(duì)象對(duì)其他對(duì)象的引用應(yīng)當(dāng)降到最低。

6.接口隔離原則(ISP)

定義：一個(gè)類(lèi)對(duì)另一個(gè)類(lèi)的依賴(lài)應(yīng)該建立在最小的接口上。

建立單一接口，不要建立龐大臃腫的接口，盡量細(xì)化接口，接口中的方法盡量少。也就是說(shuō)，我們要為各個(gè)類(lèi)建立專(zhuān)用的接口，而不要試圖去建立一個(gè)很龐大的接口供所有依賴(lài)它的類(lèi)去調(diào)用。

采用接口隔離原則對(duì)接口進(jìn)行約束時(shí)，要注意以下幾點(diǎn)：

接口盡量小，但是要有限度。對(duì)接口進(jìn)行細(xì)化可以提高程序設(shè)計(jì)靈活性，但是如果過(guò)小，則會(huì)造成接口數(shù)量過(guò)多，使設(shè)計(jì)復(fù)雜化。所以一定要適度。

為依賴(lài)接口的類(lèi)定制服務(wù)，只暴露給調(diào)用的類(lèi)它需要的方法，它不需要的方法則隱藏起來(lái)。只有專(zhuān)注地為一個(gè)模塊提供定制服務(wù)，才能建立最小的依賴(lài)關(guān)系。

提高內(nèi)聚，減少對(duì)外交互。使接口用最少的方法去完成最多的事情。

這六個(gè)原則，可以使我們?cè)趹?yīng)用的迭代維護(hù)中更加方便、輕松的應(yīng)對(duì)，讓我們的軟件更加靈活。在后續(xù)的文章中我會(huì)給大家介紹其他的設(shè)計(jì)模式

文章鏈接：http://blog.csdn.net/itachi85/article/details/50491657

本文由 @劉望舒 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理?，未經(jīng)許可，禁止轉(zhuǎn)載。