引言

對于一個軟件平臺來說，軟件平臺代碼的好壞直接影響平臺整體的質(zhì)量與穩(wěn)定性。同時也會影響著寫代碼同學(xué)的創(chuàng)作激情。想象一下如果你從git上面clone下來的的工程代碼亂七八糟，代碼晦澀難懂，難以快速入手，有種想推到重寫的沖動，那么程序猿在這個工程中寫好代碼的初始熱情都沒了。相反，如果clone下的代碼結(jié)構(gòu)清晰，代碼優(yōu)雅易懂，那么你在寫代碼的時候都不好意思寫爛代碼。這其中的差別相信工作過的同學(xué)都深有體會，那么我們看了那么多代碼之后，到底什么樣的代碼才是好代碼呢?它們有沒有一些共同的特征或者原則?本文通過闡述優(yōu)雅代碼的設(shè)計原則來和大家聊聊怎么寫好代碼。

代碼設(shè)計原則

好代碼是設(shè)計出來的，也是重構(gòu)出來的，更是不斷迭代出來的。在我們接到需求，經(jīng)過概要設(shè)計過后就要著手進行編碼了。但是在實際編碼之前，我們還需要進行領(lǐng)域分層設(shè)計以及代碼結(jié)構(gòu)設(shè)計。那么怎么樣才能設(shè)計出來比較優(yōu)雅的代碼結(jié)構(gòu)呢?有一些大神們總結(jié)出來的優(yōu)雅代碼的設(shè)計原則，我們分別來看下。

SRP

所謂SRP(Single Responsibility Principle)原則就是職責(zé)單一原則，從字面意思上面好像很好理解，一看就知道什么意思。但是看的會不一定就代表我們就會用，有的時候我們以為我們自己會了，但是在實際應(yīng)用的時候又會遇到這樣或者那樣的問題。原因就是實際我們沒有把問題想透，沒有進行深度思考，知識還只是知識，并沒有轉(zhuǎn)化為我們的能力。就比如這里所說的職責(zé)單一原則指的是誰的單一職責(zé)，是類還是模塊還是域呢?域可能包含多個模塊，模塊也可以包含多個類，這些都是問題。

為了方便進行說明，這里以類來進行職責(zé)單一設(shè)計原則的說明。對于一個類來說，如果它只負(fù)責(zé)完成一個職責(zé)或者功能，那么我們可以說這個類時符合單一職責(zé)原則。請大家回想一下，其實我們在實際的編碼過程中，已經(jīng)有意無意的在使用單一職責(zé)設(shè)計原則了。因為實際它是符合我們?nèi)怂伎紗栴}的方式的。為什么這么說呢?想想我們在整理衣柜的時候，為了方便拿衣服我們會把夏天的衣服放在一個柜子中，冬天的衣服放在一個柜子。這樣季節(jié)變化的時候，我們只要到對應(yīng)的柜子直接拿衣服就可以了。否則如果冬天和夏天的衣服都放在一個柜子中，我們找衣服的時候可就費勁了。放到軟件代碼設(shè)計中，我們也需要采用這樣的分類思維。在進行類設(shè)計的時候，要設(shè)計粒度小、功能單一的類，而不是大而全的類。

舉個栗子，在學(xué)生管理系統(tǒng)中，如果一個類中既有學(xué)生信息的操作比如創(chuàng)建或者刪除動作，又有關(guān)于課程的創(chuàng)建以及修改動作，那么我們可以認(rèn)為這個類時不滿足單一職責(zé)的設(shè)計原則的，因為它將兩個不同業(yè)務(wù)域的業(yè)務(wù)混雜在了一起，所以我們需要進行拆分，將這個大而全的類拆分為學(xué)生以及課程兩個業(yè)務(wù)域，這樣粒度更細(xì)，更加內(nèi)聚。

筆者根據(jù)自身的經(jīng)驗，總結(jié)了需要考慮進行單一職責(zé)拆分的幾個原則，希望對大家判斷是否需要進行拆分有個簡單的判斷的標(biāo)準(zhǔn)：

1、不同的業(yè)務(wù)域需要進行拆分，就像上面的例子，另外如果與其他類的依賴過多，也需要考慮是不是應(yīng)該進行拆分;

2、如果我們在類中編寫代碼的時候發(fā)現(xiàn)私有方法具有一定的通用性，比如判斷ip是不是合法，解析xml等，那我們可以考慮將這些方法抽出來形成公共的工具類，這樣其他類也可以方便的進行使用。

另外單一職責(zé)的設(shè)計思想不止在代碼設(shè)計中使用，我們在進行微服務(wù)拆分的時候也會一定程度的遵循這個原則。

OCP

OCP(Open Closed Principle)即對修改關(guān)閉，對擴展開放原則，個人覺得這是設(shè)計原則中最難的原則。不僅理解起來有一定的門檻，在實際編碼過程中也是不容易做到的。

首先我們得先搞清楚這里的所說的修改以及擴展的區(qū)別在什么地方，說實話一開始看到這個原則的時候，我總覺得修改和開放說的不是一個意思嘛?想來想去都覺得有點迷糊。后來在不斷的項目實踐中，對這個設(shè)計原則的理解逐漸加深了。

設(shè)計原則中所說的修改指的是對原有代碼的修改，而擴展指的是在原有代碼基礎(chǔ)上的能力的擴展，并不修改原先已有的代碼。這是修改與擴展的最大的區(qū)別，一個需要修改原來的代碼邏輯，另一個不修改。因此才叫對修改關(guān)閉但是對擴展開放。弄清楚修改和擴展的區(qū)別之后，我們再想一想為什么要對修改關(guān)閉，而要對擴展開放呢?我們都知道軟件平臺都是不斷進行更新迭代的，因此我們需要不斷在原先的代碼中進行開發(fā)。那么就會涉及到一個問題如果我們的代碼設(shè)計的不好，擴展性不強，那么每次進行功能迭代的時候都會修改原先已有的代碼，有修改就有可能引入bug，造成系統(tǒng)平臺的不穩(wěn)定。因此我們?yōu)榱似脚_的穩(wěn)定性，需要對修改關(guān)閉。但是我們要添加新的功能怎么辦呢?那就是通過擴展的方式來進行，因此需要實現(xiàn)對擴展開放。

這里我們以一個例子來進行說明，否則可能還是有點抽象。在一個監(jiān)控平臺中，我們需要對服務(wù)所占用CPU、內(nèi)存等運行信息進行監(jiān)控，第一版代碼如下。

public class Alarm {
 private AlarmRule alarmRule;
    private AlarmNotify alarmNotify;   
    public Alarm(AlarmRule alarmRule, AlarmNotify alarmNotify) {
        this.alarmRule = alarmRule;
        this.alarmNotify = alarmNotify;
    }    
    public void checkServiceStatus(String serviecName, int cpu, int memory) {
        if(cpu > alarmRule.getRule(ServiceConstant.Status).getCpuThreshold) {
            alarmNotify.notify(serviecName +  alarmRule.getRule(ServiceConstant.Status).getDescription)
        }       
         if(memory > alarmRule.getRule(ServiceConstant.Status).getMemoryThreshold) {
            alarmNotify.notify(serviecName +  alarmRule.getRule(ServiceConstant.Status).getDescription)
        }     
    }
}

代碼邏輯很簡單，就是根據(jù)對應(yīng)的告警規(guī)則中的閾值判斷是否達(dá)到觸發(fā)告警通知的條件。如果此時來了個需求，需要增加判斷的條件，就是根據(jù)服務(wù)對應(yīng)的狀態(tài)，判斷需不需要進行告警通知。我們來先看下比較low的修改方法。我們在checkServiceStatus方法中增加了服務(wù)狀態(tài)的參數(shù)，同時在方法中增加了判斷狀態(tài)的邏輯。

public class Alarm {
 private AlarmRule alarmRule;
    private AlarmNotify alarmNotify;
    
    public Alarm(AlarmRule alarmRule, AlarmNotify alarmNotify) {
        this.alarmRule = alarmRule;
        this.alarmNotify = alarmNotify;
    }   
    public void checkServiceStatus(String serviecName, int cpu, int memory， int status) {
        if(cpu > alarmRule.getRule(ServiceConstant.Status).getCpuThreshold) {
            alarmNotify.notify(serviecName +  alarmRule.getRule(ServiceConstant.Status).getDescription)
        }        
         if(memory > alarmRule.getRule(ServiceConstant.Status).getMemoryThreshold) {
            alarmNotify.notify(serviecName +  alarmRule.getRule(ServiceConstant.Status).getDescription)
        }        
         if(status == alarmRule.getRule(ServiceConstant.Status).getStatusThreshold) {
            alarmNotify.notify(serviecName +  alarmRule.getRule(ServiceConstant.Status).getDescription)
        }    
    }
}

很顯然這種修改方法非常的不友好，為什么這么說呢?首先修改了方法參數(shù)，那么調(diào)用該方法的地方可能也需要修改，另外如果改方法有單元測試方法的話，單元測試用例必定也需要修改，在原有測試過的代碼中添加新的邏輯，也增加了bug引入的風(fēng)險。因此這種修改的方式我們需要進行避免。那么怎么修改才能夠體現(xiàn)對修改關(guān)閉以及對擴展開放呢?

首先我們可以先將關(guān)于服務(wù)狀態(tài)的屬性抽象為一個ServiceStatus 實體，在對應(yīng)的檢查方法中以ServiceStatus 為入?yún)?，這樣以后如果還有服務(wù)狀態(tài)的屬性增加的話，只需要在ServiceStatus 中添加即可，并不需要修改方法中的參數(shù)以及調(diào)用方法的地方，同樣單元測試的方法也不用修改。

@Data
public class ServiceStatus {
    String serviecName;
    int cpu;
    int memory;
    int status;

}

另外在檢測方法中，我們怎么修改才能體現(xiàn)可擴展呢?而不是在檢測方法中添加處理邏輯。一個比較好的實現(xiàn)方式就是通過抽象檢測方法，具體的實現(xiàn)在各個實現(xiàn)類中。這樣即使新增檢測邏輯，只需要擴展檢測實現(xiàn)方法就可，不需要在修改原先代碼的邏輯，實現(xiàn)代碼的可擴展。

LSP

LSP(Liskov Substitution Principle)里氏替換原則，這個設(shè)計原則我覺得相較于前面的兩個設(shè)計原則來說要簡單些。它的內(nèi)容為子類對象(object of subtype/derived class)能夠替換程序(program)中父類對象(object of base/parent class)出現(xiàn)的任何地方，并且保證原來程序的邏輯行為(behavior)不變及正確性不被破壞。

里式替換原則是用來指導(dǎo)，繼承關(guān)系中子類該如何設(shè)計的一個原則。理解里式替換原則，最核心的就是理解“design by contract，按照協(xié)議來設(shè)計”這幾個字。父類定義了函數(shù)的“約定”(或者叫協(xié)議)，那子類可以改變函數(shù)的內(nèi)部實現(xiàn)邏輯，但不能改變函數(shù)原有的“約定”。這里的約定包括：函數(shù)聲明要實現(xiàn)的功能;對輸入、輸出、異常的約定;甚至包括注釋中所羅列的任何特殊說明。

我們怎么判斷有沒有違背LSP呢?我覺得有兩個關(guān)鍵點可以作為判斷的依據(jù)，一個是子類有沒有改變父類申明需要實現(xiàn)的業(yè)務(wù)功能，另一個是否違反父類關(guān)于輸入、輸出以及異常拋出的規(guī)定。

ISP

ISP(Interface Segregation Principle)接口隔離原則，簡單理解就是只給調(diào)用方需要的接口，它不需要的就不要硬塞給他了。這里我們舉個栗子，以下是關(guān)于產(chǎn)品的接口，其中包含了創(chuàng)建產(chǎn)品、刪除產(chǎn)品、根據(jù)ID獲取產(chǎn)品以及更新產(chǎn)品的接口。如果此時我們需要對外提供一個根據(jù)產(chǎn)品的類別獲取產(chǎn)品的接口，我們應(yīng)該怎么辦?很多同學(xué)會說，這還不簡單，我們直接在這個接口里面添加根據(jù)類別查詢產(chǎn)品的接口就OK了啊。大家想想這個方案有沒有什么問題。

public interface ProductService { 
    boolean createProduct(Product product); 
    boolean deleteProductById(long id); 
    Product getProductById(long id); 
    int updateProductInfo(Product product);
}
public class UserServiceImpl implements UserService { //...}

這個方案看上去沒什么問題，但是再往深處想一想，外部系統(tǒng)只需要一個根據(jù)產(chǎn)品類別查詢商品的功能，，但是實際我們提供的接口中還包含了刪除、更新商品的接口。如果這些接口被其他系統(tǒng)誤調(diào)了可能會導(dǎo)致產(chǎn)品信息的刪除或者誤更新。因此我們可以將這些第三方調(diào)用的接口都隔離出來，這樣就不存在誤調(diào)用以及接口能力被無序擴散的情況了。

public interface ProductService { 
    boolean createProduct(Product product); 
    boolean deleteProductById(long id); 
    Product getProductById(long id); 
    int updateProductInfo(Product product);
}
public interface ThirdSystemProductService{
    List<Product> getProductByType(int type);
}
public class UserServiceImpl implements UserService { //...}

LOD

LOD(Law of Demeter)即迪米特法則，這是我們要介紹的最后一個代碼設(shè)計法則了，光從名字上面上看，有點不明覺厲的感覺，看不出來到底到底想表達(dá)什么意思。我們可以來看下原文是怎么描述這個設(shè)計原則的。

Each unit should have only limited knowledge about other units: only units “closely” related to the current unit. Or: Each unit should only talk to its friends; Don’t talk to strangers.

按照我自己的理解，這迪米特設(shè)計原則的最核心思想或者說最想達(dá)到的目的就是盡最大能力減小代碼修改帶來的對原有的系統(tǒng)的影響。所以需要實現(xiàn)類、模塊或者服務(wù)能夠?qū)崿F(xiàn)高內(nèi)聚、低耦合。不該有直接依賴關(guān)系的類之間，不要有依賴;有依賴關(guān)系的類之間，盡量只依賴必要的接口。迪米特法則是希望減少類之間的耦合，讓類越獨立越好。每個類都應(yīng)該少了解系統(tǒng)的其他部分。一旦發(fā)生變化，需要了解這一變化的類就會比較少。打個比方這就像抗戰(zhàn)時期的的地下組織一樣，相關(guān)聯(lián)的聚合到一起，但是與外部保持盡可能少的聯(lián)系，也就是低耦合。

總結(jié)

本文總結(jié)了軟件代碼設(shè)計中的五大原則，按照我自己的理解，這五大原則就是程序猿代碼設(shè)計的內(nèi)功，而二十三種設(shè)計模式實際就是內(nèi)功催生出來的編程招式，因此深入理解五大設(shè)計原則是我們用好設(shè)計模式的基礎(chǔ)，也是我們在平時設(shè)計代碼結(jié)構(gòu)的時候需要遵循的一些常見規(guī)范。只有不斷的在設(shè)計代碼-》遵循規(guī)范-》編寫代碼-》重構(gòu)這個循環(huán)中磨礪，我們才能編寫出優(yōu)雅的代碼。