SOLID 設計原則

lcbp發表於2019-04-10
Solid

考慮程式碼結構，使程式碼易於維護、易於擴充套件、易於閱讀。

SRP

Single Responsibility Principle 單一功能原則

職責單一，一個類只有一種修改的原因。

每個類都有它該在的地方，也只能在它該在的地方。

例如：

　　Controller 類，只接受使用者輸入，返回輸出，不需要具體處理背後的事情。當需要表單驗證的時候，注入相應的 Request 類。當需要資料操作時，注入相應的 Repository 或 Service 或 Factory。

　　Model 類，將修改器，訪問器定義在 trait 然後 use 進來。資料操作邏輯分離成 Repository。

　　Helper.php 全域性函式，將同型別的 helper 分離成單獨的檔案，使其高內聚。然後在 Helper.php 中引入。

OCP

Open/Close Principle 開閉原則

不更改類的前提下，能擴充套件類的行為

例如：
所有具體的類都需要實現 Interface 中定義的方法。
在 Factory 中例項化具體的類。
在 Controller 中使用 Factory。

首先建立一個 PaymentInterface，任何支付方式都必須實現此介面中定義的方法。

interface PaymentInterface {
    public function pay();
}

接著，建立兩個實現 PaymentInterface 的具體類。

class Alipay implements PaymentInterface {
    public function pay() {
        // 支付寶支付具體程式碼
    }
}
class Wechat implements PaymentInterface {
    public function pay() {
        // 微信支付具體程式碼
    }
}

然後，建立一個支付工廠，此工廠用來例項化具體的支付類

class PeymentFactory
{
    public function init($payType) {
        switch ($payType) {
            case 'Alipay':
                return new Alipay();
            case 'Wechat':
                return new Wechat();
        }
        throw new Exception('未知支付方式');
    }
}

最後，在控制器中注入此 Factory

public function pay (Request $request, PaymentFactory $paymentFactory) {
    $payment = $paymentFactory->init($request->payType);
    $payment->pay();
}

LSP

Liskov Substitution Principle 里氏替換原則

子類要可以替代父類

ISP

Interface Segregation Principle 介面隔離原則

使用客戶端特定的細粒度介面

使用非內聚介面時，建立多個較小的高內聚介面。不要強迫呼叫者去依賴他不適用的介面。

DIP

Dependency Inversion Principle 依賴反轉原則

依賴抽象介面，而不是具體實現

將高層次元件對低層次元件的依賴解耦出來，例如「類A」原本依賴於「類B」，那麼新建 「InterfaceB」，讓「類A」改為依賴於「InterfaceB」，讓「類B」去實現「InterfaceB」 規定的介面方法。

依賴注入 DI

一個類，如果依賴另一個類的功能，就透過注入方式實現。比如在構造方法中引入。

控制反轉 IOC

將建立例項的控制權剝離出來，交給IOC容器控制。

本作品採用《CC 協議》，轉載必須註明作者和本文連結

相關文章