引言

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

代碼設計原則

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

SRP

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

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

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

筆者根據自身的經驗，總結了需要考慮進行單一職責拆分的幾個原則，希望對大家判斷是否需要進行拆分有個簡單的判斷的標準：

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

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

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

OCP

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

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

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

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

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)
        }     
    }
}

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

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)
        }    
    }
}

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

首先我們可以先將關于服務狀態的屬性抽象為一個ServiceStatus 實體，在對應的檢查方法中以ServiceStatus 為入參，這樣以后如果還有服務狀態的屬性增加的話，只需要在ServiceStatus 中添加即可，并不需要修改方法中的參數以及調用方法的地方，同樣單元測試的方法也不用修改。

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

}

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

LSP

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

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

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

ISP

ISP(Interface Segregation Principle)接口隔離原則，簡單理解就是只給調用方需要的接口，它不需要的就不要硬塞給他了。這里我們舉個栗子，以下是關于產品的接口，其中包含了創建產品、刪除產品、根據ID獲取產品以及更新產品的接口。如果此時我們需要對外提供一個根據產品的類別獲取產品的接口，我們應該怎么辦?很多同學會說，這還不簡單，我們直接在這個接口里面添加根據類別查詢產品的接口就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 { //...}

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

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)即迪米特法則，這是我們要介紹的最后一個代碼設計法則了，光從名字上面上看，有點不明覺厲的感覺，看不出來到底到底想表達什么意思。我們可以來看下原文是怎么描述這個設計原則的。

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.

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

總結

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