本文轉(zhuǎn)載自微信公眾號(hào)「Java極客技術(shù)」，作者鴨血粉絲Tang。轉(zhuǎn)載本文請(qǐng)聯(lián)系Java極客技術(shù)公眾號(hào)。

在實(shí)際的軟件編程過程中，代碼設(shè)計(jì)的合理性會(huì)直接決定項(xiàng)目的開發(fā)復(fù)雜程度，一個(gè)好的設(shè)計(jì)模型，會(huì)讓你的軟件開發(fā)過程順暢無比!

一、介紹

在 1994 年，由 Erich Gamma、Richard Helm、Ralph Johnson 和 John Vlissides 四人合著出版了一本名為 Design Patterns - Elements of Reusable Object-Oriented Software(中文譯名：設(shè)計(jì)模式 - 可復(fù)用的面向?qū)ο筌浖? 的書，該書首次提到了軟件開發(fā)中設(shè)計(jì)模式的概念，四位作者合稱 GOF(全拼 Gang of Four)，簡(jiǎn)稱四人幫!

書中共說到 23 種設(shè)計(jì)模式，這些模式可以分為三大類：創(chuàng)建型模式(Creational Patterns)、結(jié)構(gòu)型模式(Structural Patterns)、行為型模式(Behavioral Patterns)。

當(dāng)然，隨著軟件的快速發(fā)展，還出現(xiàn)另一類我們所熟知的設(shè)計(jì)模式：J2EE 設(shè)計(jì)模式。

首先要跟大家說明的是，設(shè)計(jì)模式其實(shí)不是一項(xiàng)新技術(shù)，而是眾多軟件開發(fā)人員經(jīng)過相當(dāng)長(zhǎng)的一段時(shí)間的試用和試錯(cuò)總結(jié)出來的一套軟件設(shè)計(jì)開發(fā)實(shí)踐方案，學(xué)習(xí)這些知識(shí)有助于經(jīng)驗(yàn)不足的開發(fā)人員通過一種簡(jiǎn)單快捷的方式來學(xué)習(xí)軟件設(shè)計(jì)。

也不BB了，下面我們就一起來深入了解一下大神們總結(jié)的這套方法論!

二、方法論

2.1、單一職責(zé)原則

單一職責(zé)原則，顧名思義，一個(gè)類負(fù)責(zé)一個(gè)功能的處理，比如我們?cè)诖a中經(jīng)常會(huì)涉及到調(diào)用第三方的接口，通常我們往往會(huì)將一個(gè)接口請(qǐng)求方法封裝成一個(gè)http請(qǐng)求的工具類，這樣其他的調(diào)用方能非常方便的進(jìn)行調(diào)用。

單一職責(zé)原則，主要的目的是將一個(gè)功能劃分到合適的粒度，讓這些各自執(zhí)行單一職責(zé)的類，各司其職。

還有我們常常說的mvc模式，將數(shù)據(jù)操作與業(yè)務(wù)邏輯處理進(jìn)行分離，也是屬于單一職責(zé)原則的一種。

2.2、開閉原則

開閉原則，指的是：對(duì)擴(kuò)展開放，對(duì)修改關(guān)閉。

這里的意思是在增加新功能的時(shí)候，能不改代碼就盡量不要改，如果只增加代碼就完成了新功能，那是最好的。

下面我舉個(gè)簡(jiǎn)單的例子，大家可能就懂了。

在實(shí)際的項(xiàng)目開發(fā)過程中，尤其是與第三方公司進(jìn)行接口對(duì)接的時(shí)候，例如 a 公司，他的接口協(xié)議要求采用rsa加密;b 公司，他的接口協(xié)議采用aes加密，c公司，他的接口協(xié)議要求采用md5就可以了...

在一開始的時(shí)候，可能你沒有想那么多，設(shè)想所有其他公司跟你對(duì)接的時(shí)候，全部采用rsa加密，那么當(dāng)?shù)诙夜緛砹藭r(shí)候，要求采用aes，這個(gè)時(shí)候，你必須得改代碼才能支持這種功能，假如又來了其他公司呢?

在這種情況下，我們可以采用面向接口編程的思想，定義一個(gè)抽象的方法，然后針對(duì)不同的加密算法，編寫不同的實(shí)現(xiàn)類，當(dāng)新來了一家公司要求采用不同的加密算法時(shí)，我們只需要擴(kuò)展一個(gè)新的實(shí)現(xiàn)類，在邏輯處理層進(jìn)行路由即可快速完成開發(fā)和對(duì)接!

實(shí)現(xiàn)開閉原則的主要步驟就是將業(yè)務(wù)方法里面的邏輯進(jìn)行抽象化，從而實(shí)現(xiàn)邏輯層面代碼的解耦。

2.3、里氏代換原則

里氏替換原則，通俗的說就是：子類可以擴(kuò)展父類的功能，但不能改變父類原有的功能。

也就是說：子類繼承父類時(shí)，除添加新的方法完成新增功能外，盡量不要重寫父類的方法。

當(dāng)子類在重寫父類的方法時(shí)，如果使用不當(dāng)，很可能會(huì)改變父類方法中的邏輯語義，進(jìn)而造成邏輯處理混亂。

在實(shí)際的業(yè)務(wù)開發(fā)中，尤其是大家在使用類繼承操作時(shí)，應(yīng)當(dāng)謹(jǐn)慎重新父類方法，方法定義的時(shí)候，名稱也盡量不要發(fā)生重名。

同時(shí)，應(yīng)該注意類過多的繼承，例如 A 類繼承自 B 類，B 類 繼承自 C 類，C 類繼承 D 類，這種場(chǎng)景下，第一：邏輯很可能非常復(fù)雜，代碼可讀性可能很差，第二種可能會(huì)出現(xiàn)方法名或者屬性名沖突。

我曾經(jīng)修改一個(gè)老項(xiàng)目 bug 的時(shí)候，就出現(xiàn)過這種情況，一個(gè)實(shí)體類出現(xiàn)三層關(guān)系的繼承，當(dāng)我把子類進(jìn)行序列化成json的時(shí)候，突然報(bào)錯(cuò)，原因就是因?yàn)槔锩嬗袀€(gè)屬性，在基類里面也定義了，但是類型卻不一樣，也就是說在這個(gè)子類里面有兩個(gè)相同的屬性，只是字段類型不同而已，從而導(dǎo)致這個(gè)序列化報(bào)錯(cuò)。

因此，大家在使用類繼承操作時(shí)，一定要謹(jǐn)慎處理，最好的情況下是一層關(guān)系繼承，這樣即使出現(xiàn)問題了，也好排查，范圍可控;繼承關(guān)系多了，反而代碼變的非常復(fù)雜，每個(gè)方法邏輯都需要一一梳理清楚，你才敢去下手，這種情況下，反而為難了自己!

2.4、依賴倒轉(zhuǎn)原則

依賴倒轉(zhuǎn)原則，簡(jiǎn)單的說就是面向接口編程，依賴于抽象而不依賴于具體，他是實(shí)現(xiàn)開閉原則的一個(gè)途徑。

依賴倒轉(zhuǎn)原則主要有以下幾點(diǎn)：

• 高層的模塊不應(yīng)該依賴于低層的模塊，這兩者都應(yīng)該依賴于其抽象
• 抽象不應(yīng)該依賴細(xì)節(jié)
• 細(xì)節(jié)應(yīng)該依賴抽象

換句話說，就是將具體類里面的方法進(jìn)行邏輯抽象化，提升到接口或者抽象類里面，由具體的實(shí)現(xiàn)類去實(shí)現(xiàn)具體的業(yè)務(wù)邏輯，抽象層不關(guān)注細(xì)節(jié)。

也就是我們俗稱的，不管遇到啥事情，先看大局，在看小點(diǎn)。

舉個(gè)例子，例如我們常常使用的MVC框架，在Service層通常會(huì)先編寫接口類，然后在編寫服務(wù)實(shí)現(xiàn)類，這就是典型的面向接口編程，這種方案有哪些好處呢?

• 可以減少研發(fā)人員并行開發(fā)引起的風(fēng)險(xiǎn)
• 可以顯著提高代碼的可讀性和可維護(hù)性
• 可以降低類間的耦合性

當(dāng)一個(gè)大項(xiàng)目開發(fā)的時(shí)候，試想一下，如果2個(gè)以上研發(fā)人員在編寫同一個(gè)類的同一個(gè)方法，沒有定義接口的情況下，隨著時(shí)間的流逝，這個(gè)類大概率會(huì)非常混亂，同時(shí)，里面的方法估計(jì)閱讀起來也很困難，一眼望去基本上不知道這個(gè)方法是干嘛的，尤其是重載方法很多的時(shí)候，尤其困難。

當(dāng)我們引入接口之后，將所有的核心方法全部抽象定義，當(dāng)我們對(duì)其進(jìn)行二次開發(fā)的時(shí)，也會(huì)能快速定位到以前的和諧方法，然后進(jìn)行快速定位和維護(hù)。

面向接口編程，還有一個(gè)很大的好處，就是可以降低類之間的耦合度。

2.5、接口隔離原則

接口隔離原則的意思是：盡量將一個(gè)接口拆的更細(xì)，使用多個(gè)隔離的接口，比使用單個(gè)接口要好。

這個(gè)原則基本上是從大型軟件架構(gòu)出發(fā)、便于升級(jí)和維護(hù)的思想誕生出來的。

比如，一個(gè)第三方保險(xiǎn)服務(wù)系統(tǒng)里面，如果是小項(xiàng)目，你可以在一個(gè)接口里面定義投保方法、取消方法、 退保方法、 理賠方法、 保單方法這5種方法。

當(dāng)你只跟一家保險(xiǎn)公司合作的時(shí)候，這套接口定義是沒問題的，但是假如現(xiàn)在公司的業(yè)務(wù)發(fā)展的非?？?，已經(jīng)引入10幾家保險(xiǎn)公司了，你會(huì)發(fā)現(xiàn)這個(gè)接口基本上頂不住了，在此有兩種方法可以解決這種技術(shù)難題：

• 針對(duì)不同的保險(xiǎn)公司，又重新定義一個(gè)接口，然后還是里面的5種方法
• 針對(duì)不同的操作行為，比如投保，單獨(dú)定義一套接口，然后針對(duì)不同的保險(xiǎn)公司編寫不同的實(shí)現(xiàn)類

這兩種其實(shí)本質(zhì)都是將一個(gè)接口，拆成多個(gè)顆粒度更細(xì)的接口，然后從行為上，讓各種的實(shí)現(xiàn)類更加獨(dú)立，進(jìn)而降低類之間的耦合度，開發(fā)起來層次清晰，有利于系統(tǒng)的穩(wěn)定!

2.6、組合/聚合復(fù)用原則

合成復(fù)用原則的意思就是：盡量使用組合/聚合的方式，而不是使用繼承。

所謂組合/聚合的方式，其實(shí)就是我們?cè)趕pringMVC里面使用的ioc依賴注入方式，

@Component
public class AService {

 /**
     * ioc依賴注入
     */
    @Autowired
    private BService bService;

 //業(yè)務(wù)代碼...
}

AService類調(diào)用BService類，有兩種方式可以實(shí)現(xiàn)，第一種就是通過繼承方式，可以直接調(diào)用;第二種方式就是通過ioc依賴注入的方式，在類里面進(jìn)行組合操作，然后進(jìn)行調(diào)用。

很明顯，第二種方式，我們使用的愛不釋手!

這種方式有個(gè)好處就是，代碼層次清晰，編寫優(yōu)雅，用上之后容易上癮，推薦使用!

2.7、迪米特法則

迪米特法則，又稱最少知道原則，意思就是說：一個(gè)實(shí)體應(yīng)當(dāng)盡量少地與其他實(shí)體之間發(fā)生相互作用，使得系統(tǒng)功能模塊相對(duì)獨(dú)立。

類似單一原則的思想，例如我們編寫實(shí)體類的時(shí)候，基本上就是屬性名稱，加get/set。

public class User {

 /**
     * 用戶id
     */
    private Long userId;

 /**
     * 用戶姓名
     */
 private String userName;


 public Long getUserId(){
  return this.userId;
 }

 public void setUserId(Long userId){
  this.userId = userId;
 }

 public String getUserName(){
  return this.userName;
 }

 public void setUserName(String userName){
  this.userName = userName;
 }

}

當(dāng)一個(gè)實(shí)體里面出現(xiàn)跟自己沒太大關(guān)系的代碼時(shí)，例如數(shù)據(jù)運(yùn)算邏輯處理，這個(gè)時(shí)候應(yīng)當(dāng)將這部分代碼全部清理出去，交由業(yè)務(wù)處理層來出來。

從實(shí)體類的定義來說，它主要的功能就是承擔(dān)數(shù)據(jù)展示，當(dāng)多個(gè)業(yè)務(wù)處理層在使用這個(gè)實(shí)體類的時(shí)候，如果你們嵌套了很多的數(shù)據(jù)運(yùn)算邏輯，可能在返回的時(shí)候，客戶端得到的實(shí)體類的屬性值，并不是正確的結(jié)果!

三、小結(jié)

上面一共介紹了 7 種設(shè)計(jì)原則，基本上都是大神們經(jīng)過很多次血的教訓(xùn)，總結(jié)出來的一套方法論。

這些設(shè)計(jì)原則，可以給同行在實(shí)際的軟件設(shè)計(jì)過程中，提供一些思路，具體的應(yīng)用，還需要結(jié)合實(shí)際的業(yè)務(wù)場(chǎng)景進(jìn)一步思考，怎么讓系統(tǒng)變的更加可靠，開發(fā)更佳迅速，代碼閱讀起來更佳輕松，關(guān)鍵在于靈活運(yùn)用!