摘要：面向?qū)ο蠡驹瓌t單一職責(zé)原則與接口隔離原則面向?qū)ο蠡驹瓌t單一職責(zé)原則與接口隔離原則面向?qū)ο蠡驹瓌t里式代換原則與依賴倒置原則面向?qū)ο蠡驹瓌t最少知道原則與開閉原則一單一職責(zé)原則單一職責(zé)原則簡介單一職責(zé)原則的英文名稱是，簡稱。

面向?qū)ο蠡驹瓌t（1）- 單一職責(zé)原則與接口隔離原則
面向?qū)ο蠡驹瓌t（2）- 里式代換原則與依賴倒置原則
面向?qū)ο蠡驹瓌t（3）- 最少知道原則與開閉原則

單一職責(zé)原則的英文名稱是 Single Responsibility Principle，簡稱SRP。
單一職責(zé)原則的原話解釋是：

There should never be more than one reason for a class to change.

意思是：應(yīng)該有且僅有一個原因引起類的變更。

類的復(fù)雜性降低，實現(xiàn)什么職責(zé)都有清晰明確的定義。

可讀性提高，復(fù)雜性降低，那當(dāng)然可讀性提高了。

可維護性提高，可讀性提高，那當(dāng)然更容易維護了。

變更引起的風(fēng)險降低，變更是必不可少的，如果接口的單一職責(zé)做得好，一個接口修改只對相應(yīng)的實現(xiàn)類有影響，對其他的接口無影響，這對系統(tǒng)的擴展性、維護性都有非常大的幫助。

接口一定要做到單一職責(zé)，類的設(shè)計盡量做到只有一個原因引起變化。

注意 單一職責(zé)原則提出了一個編寫程序的標準，用“職責(zé)”或“變化原因”來衡量接口或類設(shè)計得是否優(yōu)良，但是“職責(zé)”和“變化原因”都是不可度量的，因項目而異，因環(huán)境而異。

代碼使用PHP7.2語法編寫

IUserBo 接口負責(zé)用戶屬性

interface IUserBo
{
    public function setUserID(string $userID);

    public function getUserID() : string ;

    public function setPassword(string $password);

    public function getPassword() : string ;

    public function setUserName(string $userName);

    public function getUserName() : string ;
}

IUserBiz 接口負責(zé)用戶行為

interface IUserBiz
{
    public function changePassword(string $password) : bool ;

    public function deleteUser(IUserBo $userBo) : bool ;

    public function mapUser(IUserBo $userBo);

    public function addOrg(IUserBo $userBo, int $orgID) : bool;

    /**
     * 給用戶添加角色
     * @param IUserBo $userBo
     * @param int $roleID
     * @return bool
     */
    public function addRole(IUserBo $userBo, int $roleID) : bool ;
}

UserInfo 類實現(xiàn) IUserBo, IUserBiz 兩個接口

class UserInfo implements IUserBo, IUserBiz
{
    public function setUserID(string $userID)
    {
        // TODO: Implement setUserID() method.
    }

    public function getUserID(): string
    {
        // TODO: Implement getUserID() method.
    }

    public function setPassword(string $password)
    {
        // TODO: Implement setPassword() method.
    }

    public function getPassword(): string
    {
        // TODO: Implement getPassword() method.
    }

    public function setUserName(string $userName)
    {
        // TODO: Implement setUserName() method.
    }

    public function getUserName(): string
    {
        // TODO: Implement getUserName() method.
    }

    public function changePassword(string $password): bool
    {
        // TODO: Implement changePassword() method.
    }

    public function deleteUser(IUserBo $userBo): bool
    {
        // TODO: Implement deleteUser() method.
    }

    public function mapUser(IUserBo $userBo)
    {
        // TODO: Implement mapUser() method.
    }

    public function addOrg(IUserBo $userBo, int $orgID): bool
    {
        // TODO: Implement addOrg() method.
    }

    public function addRole(IUserBo $userBo, int $roleID): bool
    {
        // TODO: Implement addRole() method.
    }
}

$userInfo = new UserInfo();
// 賦值，就認為它是一個純粹的屬性
$userInfo->setPassword("abc");
// 執(zhí)行動作，就認為是一個業(yè)務(wù)邏輯類
$userInfo->deleteUser($userInfo);

接口隔離原則的英文名稱是 Interface Segregation Principle，簡稱ISP。
接口隔離原則的英文定義有兩種：

Clients should not be forced to depend upon interfaces that they don"t use.
客戶端不應(yīng)該被迫依賴于他們不使用的接口。

The dependency of one class to another one should depend on the smallest possible interface.
類間的依賴關(guān)系應(yīng)該建立在盡可能小的接口上。

我們可以把這兩個定義概括為一句話：建立單一接口，不要建立臃腫龐大的接口。
再通俗一點講：接口盡量細化，同時接口中的方法盡量少。

接口隔離原則與單一職責(zé)的審視角度是不相同的。
單一職責(zé)要求的是類和接口職責(zé)單一，注重的是職責(zé)，這是業(yè)務(wù)邏輯上的劃分，而接口隔離原則要求接口的方法盡量少。
例如一個接口的職責(zé)可能包含10個方法，這10個方法都放在一個接口中，并且提供給多個模塊訪問，各個模塊按照規(guī)定的權(quán)限來訪問，在系統(tǒng)外通過文檔約束“不使用的方法不要訪問”，按照單一職責(zé)原則是允許的，按照接口隔離原則是不允許的，因為它要求“盡量使用多個專門的接口”。專門的接口就是指提供給每個模塊的都應(yīng)該是單一接口，而不是建立一個龐大的臃腫的接口，容納所有的客戶端訪問。

這是接口隔離原則的核心定義，不出現(xiàn)臃腫的接口（Fat Interface）。
但是“小”是有限度的，根據(jù)接口隔離原則拆分接口時，首先必須滿足單一職責(zé)原則。

高內(nèi)聚就是提高接口、類、模塊的處理能力，減少對外的交互。
具體到接口隔離原則就是，要求在接口中盡量少使用public方法，接口是對外的承諾，承諾越少對系統(tǒng)的開發(fā)越有利，變更的風(fēng)險也就越少，同時也有利于降低成本。

接口的設(shè)計粒度越小，系統(tǒng)越靈活，這是不爭的事實。但是，靈活的同時也帶來了結(jié)構(gòu)的復(fù)雜化，開發(fā)難度增加，可維護性降低，這不是一個項目或產(chǎn)品所期望看到的，所以接口設(shè)計一定要注意適度。

接口隔離原則是對接口的定義，同時也是對類的定義，接口和類盡量使用原子接口或原子類來組裝。關(guān)于原子該怎么劃分，在實踐中可以根據(jù)以下幾個規(guī)則來衡量：

一個接口只服務(wù)于一個子模塊或業(yè)務(wù)邏輯;

通過業(yè)務(wù)邏輯壓縮接口中的public方法，接口時常去回顧，盡量讓接口達到“滿身筋骨肉”，而不是“肥嘟嘟”的一大堆方法；

已經(jīng)被污染了的接口，盡量去修改，若變更的風(fēng)險較大，則采用適配器模式進行轉(zhuǎn)化處理；

每個項目或產(chǎn)品都有特定的環(huán)境因素，環(huán)境不同，接口拆分的標準就不同。深入了解業(yè)務(wù)邏輯，根據(jù)經(jīng)驗和常識決定接口的粒度大小。接口粒度太小，導(dǎo)致接口數(shù)據(jù)劇增，開發(fā)人員嗆死在接口的海洋里；接口粒度太大，靈活性降低，無法提供定制服務(wù)，給整體項目帶來無法預(yù)料的風(fēng)險

參考文獻：《設(shè)計模式之禪》