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

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

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

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

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

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

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

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

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

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

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

代碼使用PHP7.2語法編寫

IUserBo 接口負(fù)責(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 接口負(fù)責(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 類實(shí)現(xiàn) IUserBo, IUserBiz 兩個(gè)接口

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();
// 賦值，就認(rèn)為它是一個(gè)純粹的屬性
$userInfo->setPassword("abc");
// 執(zhí)行動(dòng)作，就認(rèn)為是一個(gè)業(yè)務(wù)邏輯類
$userInfo->deleteUser($userInfo);

接口隔離原則的英文名稱是 Interface Segregation Principle，簡(jiǎn)稱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)該建立在盡可能小的接口上。

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

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

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

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

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

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

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

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

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

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

參考文獻(xiàn)：《設(shè)計(jì)模式之禪》