面向對象基本原則（1）- 單一職責原則與接口隔離原則

lunaticf 發布于2019-07-01 12:49 / 2477人閱讀

摘要：面向對象基本原則單一職責原則與接口隔離原則面向對象基本原則單一職責原則與接口隔離原則面向對象基本原則里式代換原則與依賴倒置原則面向對象基本原則最少知道原則與開閉原則一單一職責原則單一職責原則簡介單一職責原則的英文名稱是，簡稱。

面向對象基本原則（1）- 單一職責原則與接口隔離原則

面向對象基本原則（1）- 單一職責原則與接口隔離原則
面向對象基本原則（2）- 里式代換原則與依賴倒置原則
面向對象基本原則（3）- 最少知道原則與開閉原則

一、單一職責原則 1. 單一職責原則簡介

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

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

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

2. 單一職責原則優點

類的復雜性降低，實現什么職責都有清晰明確的定義。

可讀性提高，復雜性降低，那當然可讀性提高了。

可維護性提高，可讀性提高，那當然更容易維護了。

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

3. 最佳實踐

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

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

4. Show me the code

代碼使用PHP7.2語法編寫

用戶業務場景

IUserBo 接口負責用戶屬性

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 接口負責用戶行為

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 類實現 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");
// 執行動作，就認為是一個業務邏輯類
$userInfo->deleteUser($userInfo);

二、接口隔離原則 1. 接口隔離原則簡介

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

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

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

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

接口隔離原則與單一職責的區別

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

2. 接口隔離原則的規范 接口要盡量小

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

接口要高內聚

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

接口只提供訪問者需要的方法 接口設計要適度

接口的設計粒度越小，系統越靈活，這是不爭的事實。但是，靈活的同時也帶來了結構的復雜化，開發難度增加，可維護性降低，這不是一個項目或產品所期望看到的，所以接口設計一定要注意適度。

3. 最佳實踐

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

一個接口只服務于一個子模塊或業務邏輯;

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

已經被污染了的接口，盡量去修改，若變更的風險較大，則采用適配器模式進行轉化處理；

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

參考文獻：《設計模式之禪》

GPU云服務器云服務器單一職責原則基本原則設計原則憲法的基本原則

文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。

轉載請注明本文地址：http://specialneedsforspecialkids.com/yun/31574.html

Java-001-面向對象

摘要：單一職責原則可以看做是低耦合高內聚在面向對象原則上的引申，將職責定義為引起變化的原因，以提高內聚性來減少引起變化的原因。抽象的穩定性決定了系統的穩定性，因為抽象是不變的，依賴于抽象是面向對象設計的精髓，也是依賴倒置原則的核心。 Java-面向對象什么是面過程把題分解成一個一個步驟，每個步驟用函數實現，依次調用即可。就是說，在進行面向過程編程的時候，不需要考慮那么多，上來先定義一個...

gekylin 2019-08-16 15:20 評論0 收藏0
PHP面向對象設計五大原則（SOLID）梳理總結

摘要：設計原則梳理，參考核心技術與最佳實踐敏捷開發原則模式與實踐，文章面向對象設計的五大原則設計模式原則單一職責原則定義特性僅有一個引起類變化的原因一個類只承擔一項職責職責變化的原因避免相同的職責分散到不同的類，功能重復問題一個類承擔的職責過多， PHP設計原則梳理，參考《PHP核心技術與最佳實踐》、《敏捷開發原則、模式與實踐》，文章PHP面向對象設計的五大原則、設計模式原則SOLID 單一...

王晗 2019-07-01 10:18 評論0 收藏0
設計模式六大原則（PHP）

摘要：常用的六大設計模式有單一職責原則，里氏替換原則，依賴倒轉原則，接口隔離原則，迪米特法則，開閉原則。這六大原則是最虛，最抽象的，很難理解。這就是接口隔離原則。當我們遵循前面介紹的五大原則，以及使用種設計模式的目的就是遵循開閉原則。　　設計模式的目的是為了更好的代碼重用性，可讀性，可靠性和可維護性。常用的六大設計模式有：單一職責原則（SRP），里氏替換原則（LSP），依賴倒轉原則（DIP...

bluesky 2019-07-01 10:05 評論0 收藏0
PHP面向對象設計的五大原則

摘要：面向對象設計的五大原則單一職責原則接口隔離原則開放封閉原則替換原則依賴倒置原則。主要是針對繼承的設計原則，繼承與派生多態是的主要特性。面向對象設計的五大原則：單一職責原則、接口隔離原則、開放-封閉原則、替換原則、依賴倒置原則。這些原則主要是由Robert C.Martin在《敏捷軟件開發——原則、方法、與實踐》一書中總結出來，這五大原則也是23種設計模式的基礎。單一職責原則 Sin...

adam1q84 2019-06-28 18:35 評論0 收藏0
Java設計模式-六大原則

摘要：依賴倒置原則是個設計原則中最難以實現的原則，它是實現開閉原則的重要途徑，依賴倒置原則沒有實現，就別想實現對擴展開放，對修改關閉。 1、單一職能原則（Single Responsibility Principle, SRP）定義 There should never be more than one reason for a class to change.應該有且僅有一個原因引起類的...

molyzzx 2019-08-16 18:00 評論0 收藏0