聊聊PHP物件導向設計的五個基準原則（S.O.L.I.D）

本篇文章帶大家瞭解一下PHP物件導向設計的五個基準原則（S.O.L.I.D），希望對大家有所幫助！

PHP

前端（vue）入門到精通課程：進入學習

S.O.L.I.D 是 物件導向設計(OOD)的 5 個準則的首字母縮寫 ，這些準則是由 Robert C. Martin 提出的, 他更為人所熟知的名字是 Uncle Bob。

這些準則使得開發出易擴充套件、可維護的軟體變得更容易。也使得程式碼更精簡、易於重構。同樣也是敏捷開發和自適應軟體開發的一部分。

備註: 這不是一篇簡單的介紹「歡迎來到 _*S.O.L.I.D*」的文章，這篇文章想要闡明 *S.O.L.I.D*** 是什麼。

S.O.L.I.D 意思是：

擴充套件出來的首字母縮略詞看起來可能很複雜，實際上它們很容易理解。

S - 單一功能原則
O - 開閉原則
L - 里氏替換原則
I - 介面隔離原則
D - 依賴反轉原則

接下來讓我們看看每個原則，來了解為什麼 S.O.L.I.D 可以幫助我們成為更好的開發人員。

單一職責原則

縮寫是 S.R.P ，該原則內容是:

一個類有且只能有一個因素使其改變，意思是一個類只應該有單一職責．

例如，假設我們有一些圖形，並且想要計算這些圖形的總面積．是的，這很簡單對不對？

class Circle {
    public $radius;

    public function __construct($radius) {
        $this->radius = $radius;
    }
}

class Square {
    public $length;

    public function __construct($length) {
        $this->length = $length;
    }
}

首先，我們建立圖形類，該類的構造方法初始化必要的引數．接下來，建立AreaCalculator 類，然後編寫計算指定圖形總面積的邏輯程式碼．

class AreaCalculator {

    protected $shapes;

    public function __construct($shapes = array()) {
        $this->shapes = $shapes;
    }

    public function sum() {
        // logic to sum the areas
    }

    public function output() {
        return 'Sum of the areas of provided shapes: ' . $this->sum();
    }
}

AreaCalculator 使用方法，我們只需簡單的範例化這個類，並且傳遞一個圖形陣列，在頁面底部展示輸出內容．

$shapes = array(
    new Circle(2),
    new Square(5),
    new Square(6)
);

$areas = new AreaCalculator($shapes);

echo $areas->output();

輸出方法的問題在於，AreaCalculator 處理了資料輸出邏輯．因此，假如使用者希望將資料以 json 或者其他格式輸出呢？

所有邏輯都由 AreaCalculator 類處理，這恰恰違反了單一職責原則(SRP); AreaCalculator 類應該只負責計算圖形的總面積，它不應該關心使用者是想要json還是HTML格式資料。

因此，要解決這個問題，可以建立一個 SumCalculatorOutputter 類，並使用它來處理所需的顯示邏輯，以處理所有圖形的總面積該如何顯示。

SumCalculatorOutputter 類的工作方式如下：

$shapes = array(
    new Circle(2),
    new Square(5),
    new Square(6)
);

$areas = new AreaCalculator($shapes);
$output = new SumCalculatorOutputter($areas);

echo $output->JSON();
echo $output->HAML();
echo $output->HTML();
echo $output->JADE();

現在，無論你想向使用者輸出什麼格式資料，都由 SumCalculatorOutputter 類處理。

開閉原則

物件和實體應該對擴充套件開放，但是對修改關閉．

簡單的說就是，一個類應該不用修改其自身就能很容易擴充套件其功能．讓我們看一下 AreaCalculator 類，特別是 sum 方法．

public function sum() {
    foreach($this->shapes as $shape) {
        if(is_a($shape, 'Square')) {
            $area[] = pow($shape->length, 2);
        } else if(is_a($shape, 'Circle')) {
            $area[] = pi() * pow($shape->radius, 2);
        }
    }

    return array_sum($area);
}

如果我們想用 sum 方法能計算更多圖形的面積，我們就不得不新增更多的 if/else blocks ，然而這違背了開閉原則．

讓這個 sum 方法變得更好的方式是將計算每個形狀面積的程式碼邏輯移出 sum 方法，將其放進各個形狀類中：

class Square {
    public $length;

    public function __construct($length) {
        $this->length = $length;
    }

    public function area() {
        return pow($this->length, 2);
    }
}

相同的操作應該被用來處理 Circle 類, 在類中新增一個 area 方法。現在，計算任何形狀面積之和應該像下邊這樣簡單：

public function sum() {
    $area = [];
    foreach($this->shapes as $shape) {
        $area[] = $shape->area();
    }

    return array_sum($area);
}

接下來我們可以建立另一個形狀類並在計算總和時傳遞它而不破壞我們的程式碼。然而現在又出現了另一個問題，我們怎麼能知道傳入 AreaCalculator 的物件實際上是一個形狀，或者形狀物件中有一個 area 方法？

介面編碼是實踐 S.O.L.I.D 的一部分，例如下面的例子中我們建立一個介面類，每個形狀類都會實現這個介面類：

interface ShapeInterface {
    public function area();
}

class Circle implements ShapeInterface {
    public $radius;

    public function __construct($radius) {
        $this->radius = $radius;
    }

    public function area() {
        return pi() * pow($this->radius, 2);
    }
}

在我們的 AreaCalculator 的 sum 方法中，我們可以檢查提供的形狀類的範例是否是 ShapeInterface 的實現，否則我們就丟擲一個異常：

public function sum() {
    $area = [];
    foreach($this->shapes as $shape) {
        if(is_a($shape, 'ShapeInterface')) {
            $area[] = $shape->area();
            continue;
        }

        throw new AreaCalculatorInvalidShapeException;
    }

    return array_sum($area);
}

里氏替換原則

如果對每一個型別為 T1的物件 o1，都有型別為 T2 的物件o2，使得以 T1定義的所有程式 P 在所有的物件 o1 都代換成 o2 時，程式 P 的行為沒有發生變化，那麼型別 T2 是型別 T1 的子型別。

這句定義的意思是說：每個子類或者衍生類可以毫無問題地替代基礎類別/父類別。

依然使用 AreaCalculator 類, 假設我們有一個 VolumeCalculator 類，這個類繼承了 AreaCalculator 類：

class VolumeCalculator extends AreaCalulator {
    public function construct($shapes = array()) {
        parent::construct($shapes);
    }

    public function sum() {
        // logic to calculate the volumes and then return and array of output
        return array($summedData);
    }
}

SumCalculatorOutputter 類:

class SumCalculatorOutputter {
    protected $calculator;

    public function __constructor(AreaCalculator $calculator) {
        $this->calculator = $calculator;
    }

    public function JSON() {
        $data = array(
            'sum' => $this->calculator->sum();
        );

        return json_encode($data);
    }

    public function HTML() {
        return 'Sum of the areas of provided shapes: ' . $this->calculator->sum();
    }
}

如果我們執行像這樣一個例子：

$areas = new AreaCalulator($shapes);
$volumes = new VolumeCalculator($solidShapes);

$output = new SumCalculatorOutputter($areas);
$output2 = new SumCalculatorOutputter($volumes);

程式不會出問題，但當我們使用$output2 物件呼叫 HTML 方法時，我們接收到一個 E_NOTICE 錯誤，提示我們陣列被當做字串使用的錯誤。

為了修復這個問題，只需：

public function sum() {
    // logic to calculate the volumes and then return and array of output
    return $summedData;
}

而不是讓VolumeCalculator 類的 sum 方法返回陣列。

$summedData 是一個浮點數、雙精度浮點數或者整型。

介面隔離原則

使用方（client）不應該依賴強制實現不使用的介面，或不應該依賴不使用的方法。

繼續使用上面的 shapes 例子，已知擁有一個實心塊，如果我們需要計算形狀的體積，我們可以在 ShapeInterface 中新增一個方法：

interface ShapeInterface {
    public function area();
    public function volume();
}

任何形狀建立的時候必須實現 volume 方法，但是【平面】是沒有體積的，實現這個介面會強制的讓【平面】類去實現一個自己用不到的方法。

ISP 原則不允許這麼去做，所以我們應該建立另外一個擁有 volume 方法的SolidShapeInterface 介面去代替這種方式，這樣類似立方體的實心體就可以實現這個介面了：

interface ShapeInterface {
    public function area();
}

interface SolidShapeInterface {
    public function volume();
}

class Cuboid implements ShapeInterface, SolidShapeInterface {
    public function area() {
        //計算長方體的表面積
    }

    public function volume() {
        // 計算長方體的體積
    }
}

這是一個更好的方式，但是要注意提示型別時不要僅僅提示一個 ShapeInterface 或 SolidShapeInterface。
你能建立其它的介面，比如 ManageShapeInterface ,並在平面和立方體的類上實現它，這樣你能很容易的看到有一個用於管理形狀的api。例：

interface ManageShapeInterface {
    public function calculate();
}

class Square implements ShapeInterface, ManageShapeInterface {
    public function area() { /Do stuff here/ }

    public function calculate() {
        return $this->area();
    }
}

class Cuboid implements ShapeInterface, SolidShapeInterface, ManageShapeInterface {
    public function area() { /Do stuff here/ }
    public function volume() { /Do stuff here/ }

    public function calculate() {
        return $this->area() + $this->volume();
    }
}

現在在 AreaCalculator 類中，我們可以很容易地用 calculate替換對area 方法的呼叫，並檢查物件是否是 ManageShapeInterface 的範例，而不是 ShapeInterface 。

依賴倒置原則

最後，但絕不是最不重要的：

實體必須依賴抽象而不是具體的實現．即高等級模組不應該依賴低等級模組，他們都應該依賴抽象．

這也許聽起來讓人頭大，但是它很容易理解．這個原則能夠很好的解耦，舉個例子似乎是解釋這個原則最好的方法：

class PasswordReminder {
    private $dbConnection;

    public function __construct(MySQLConnection $dbConnection) {
        $this->dbConnection = $dbConnection;
    }
}

首先 MySQLConnection 是低等級模組，然而　PasswordReminder 是高等級模組，但是根據 S.O.L.I.D. 中 D 的解釋：依賴於抽象而不依賴與實現，上面的程式碼段違背了這一原則，因為 PasswordReminder 類被強制依賴於 MySQLConnection 類．

稍後，如果你希望修改資料庫驅動，你也不得不修改 PasswordReminder 類，因此就違背了 Open-close principle．

此 PasswordReminder 類不應該關注你的應用使用了什麼資料庫，為了進一步解決這個問題，我們「面向介面寫程式碼」，由於高等級和低等級模組都應該依賴於抽象，我們可以建立一個介面：

interface DBConnectionInterface {
    public function connect();
}

這個介面有一個連線資料庫的方法，MySQLConnection 類實現該介面，在 PasswordReminder 的構造方法中不要直接將型別約束設定為 MySQLConnection 類，而是設定為介面類，這樣無論你的應用使用什麼型別的資料庫，PasswordReminder 類都能毫無問題地連線資料庫，且不違背 開閉原則．

class MySQLConnection implements DBConnectionInterface {
    public function connect() {
        return "Database connection";
    }
}

class PasswordReminder {
    private $dbConnection;

    public function __construct(DBConnectionInterface $dbConnection) {
        $this->dbConnection = $dbConnection;
    }
}

從上面一小段程式碼，你現在能看出高等級和低等級模組都依賴於抽象了。

總結

說實話，S.O.L.I.D 一開始似乎很難掌握，但只要不斷地使用和遵守其原則，它將成為你的一部分，使你的程式碼易被擴充套件、修改，測試，即使重構也不容易出現問題。

推薦學習：《》

以上就是聊聊PHP物件導向設計的五個基準原則（S.O.L.I.D）的詳細內容，更多請關注TW511.COM其它相關文章！