對於PHP物件導向設計五大原則（SOLID）的總結-php教程-PHP中文網

這篇文章主要介紹了關於PHP物件導向設計五大原則（SOLID）的總結，有著一定的參考價值，現在分享給大家，有需要的朋友可以參考一下

PHP設計原則梳理，參考《PHP核心技術與最佳實踐》、《敏捷開發原則、模式與實踐》，文章PHP面向對象設計的五大原則、設計模式原則SOLID

單一職責原則（Single Responsibility Principle, SRP）

定義/特性

僅有一個造成類別變更的原因
一個類別只承擔一項職責（職責：變化的原因）
避免相同的職責分散到不同的類，功能重複

##問題

#一個類別承擔的職責太多，多個職責間相互依賴，一個職責的變換會影響這個類別完成其他職責的能力，當造成類別變更的原因發生時，會遭受到意想不到的破壞

遵守SPR原則優勢

#減少類別之間的耦合
：當需求改變時，只修改一個類，從而隔離了變化帶來類別對其他職責的影響
提高類別的複用性
：按需引用，一個類別負責一個職責，需求的變動只需要修改對應的類別或增加某一職責
降低類別的複雜度
：職責單一，功能分散開降低一個類別多個職責類的複雜度

程式碼範例

class ParseText
{
    private $content;
    
    public function decodeText(String $content)
    {
        // TODO: decode content
    }
    
    public function saveText()
    {
        // TODO:: save $this->content;
    }
}
/*
问题思考：
解析的文本类型会有多种-html、xml、json
保存的文本也会有多种途径-redis、mysql、file
客户端只需要解析文本时必须会引入saveText不需要的方法
两个职责之间没有强烈的依赖关系存在
任意职责需求变化都需要更改这个类
*/

/*
符合SRP的设计
职责拆分
*/

class Decoder
{
    private $content;
    
    public function decodeText(String $content)
    {
    // TODO: decode content
    }
    
    public function getText()
    {
        return $this->content;
    }
}

class Store
{
    public function save($content)
    {
        // TODE: save
    }
}

登入後複製

總結

軟體設計所做的許多內容就是發現職責並合理的分離職責間的關係。如果應用程式的變更總是同時影響多個職責，就沒必要分開職責。

介面隔離原則（Interface Segregation Principle ISP）

問題

設計應用程式時，類別的介面不是內聚的。不同的客戶端只包含集中的部分功能，但係統會強制客戶端實作模組中所有方法，並且還要編寫一些啞方法。這樣的介面變成胖介面或是介面污染，這樣的介面會為系統引入一些不當的行為，資源浪費，影響其他客戶端程式增強了耦合性等

ISP定義/特性

#不應該強迫客戶端依賴與他們不需要的方法/功能
#一個類別對一個類別的依賴應該建立在最小的介面上
介面的實作類別應該只呈現為單一職責原則

#遵循ISP原則優勢

將胖介面分離，每一組介面提供特定功能服務於特定一組的客戶端程式
對一組介面的變更不會/較小的影響到其他的介面/客戶端程序，確保介面的純潔性

解決方式

胖介面分解成多個特定客戶端的介面/多重介面分離繼承
使用委託分離接口，兩個物件參與處理同一個請求，接受請求的物件將請求委託給另一個物件處理

#程式碼範例

/*
* 公告接口
*/
interface Employee
{
    public function startWork();
    public function endWork();
}

/*
* 定义特定客户端接口
*/
interface Coder
{
    public function writeCode();
}

interface Ui
{
    public function designPage();
}

class CoderClient implements Employee, Coder
{
    public function startWork()
    {
        //TODO:: start work time
    }
    public function endWork()
    {
        //TODO:: end work time
    }
    
    public function writeCode()
    {
        //TODO:: start write code
        return 'hellow world';
    }
}
$c = new CoderClient();
echo $c->writeCode();

登入後複製

總結

胖類別會導致他們的客戶端程式之間產生不正常的並且有害的耦合關係。透過把胖客戶度分解成多個特定於客戶端的接口，客戶端緊緊依賴他們實際調用的方法，從而解除了客戶端與他們沒有調用的方法之間的依賴關係。介面隔離應做的小而少。

SRP與ISP比較

都是解決軟體設計中依賴關係原則
SRP 注意職責的劃分，主要約束類，其實是介面和方法，是程式中的細節和實作。 ISP 注重介面的隔離，約束的是接口，從更宏觀的角度對接口的抽象設計

開放-封閉原則（Open-Close Principle OCP）

#問題

隨著軟體系統規模的不斷擴大，系統的維護和修改的複雜性不斷提高。系統一處的變更往往會影響到其他模組。正確的運用OCP原則可以解決此類問題。

定義/特性

一個模組在擴展行為方面應該是開放的而在更改性方面應該是封閉的

#遵循OCP優勢

模組的行為是可擴展的，可以方便的對現有模組的行為/功能進行擴展
對於模組行為的擴充不會/較小的影響現有系統/模組

程式碼範例

/*
* 定义有固定行为的抽象接口
*/
interface Process
{
    public function action(String $content);
}

/*
* 继承抽象接口，扩展不同的行为
*/
class WriteToCache implements Process
{
    public function action(String $content)
    {
        return 'write content to cache: '.$content;
    }
}

class ParseText
{
    private $content;
    public function decodeText($content)
    {
        $this->content = $content;
    }
    
    public function addAction(Process $process)
    {
        if ($process instanceof Process) {
            return $process->action($this->content);    
        }
    }
}

$p = new ParseText();
$p->decodeText('content');
echo $p->addAction(new WriteToCache());

登入後複製

總結

OCP核心想法就是抽象介面編程，抽象相對穩定。讓類別依賴與固定的抽象，透過物件導向的繼承和多態讓類別繼承抽象，複寫其方法或固有行為，是想新的擴展方法/功能，實現擴展。 ###

里氏替换原则（Liskov Substitution Principle LSP）

问题

面向对象中大量的继承关系十分普遍和简单，这种继承规则是什么，最佳的继承层次的规则又是什么，怎样优雅的设计继承关系，子类能正确的对基类中的某些方法进行重新，这是LSP原则所要处理的问题。

定义/特性

子类必须能够替换掉他们的基类型：任何出现基类的地方都可以替换成子类并且客户端程序不会改变基类行为或者出现异常和错误，反之不行。
客户端程序只应该使用子类的抽象父类，这样可以实现动态绑定（php多态）

违反LSP原则

假设一个函数a，他的参数引用一个基类b，c是b的派生类，如果将c的对象作为b类型传递给a，会导致a出现错误的行为，那没c就违法了LSP原则。

/*
* 基类
*/
class Computer
{
    public function action($a, $b)
    {
        return $a+$b;
    }
}
/*
* 子类复习了父类方法，改变了action 的行为
* 违反了LSP原则
*/
class Client extends Computer
{
    public function action($a, $b)
    {
        return $a-$b;
    }  
}

function run(Computer $computer, $a, $b) {
    return $computer->action($a, $b);
}

echo run((new Client()), 3, 5);

登入後複製

总结

LSP是OCP得以应用的最主要的原则之一，正是因为子类性的可替换行是的基类类型在无需修改的情况下扩展功能。

依赖倒置原则（Depend Inversion Principle DIP）

问题

软件开发设计中，总是倾向于创建一些高层模块依赖底层模块，底层模块更改时直接影响到高层模块，从而迫使他们改变。DIP原则描述了高层次模块怎样调用低层次模块。

定义/特性

高层模块不应该依赖与底层模块，二者都应该依赖于抽象
抽象不应该依赖与细节，细节应该依赖于抽象

代码示例

interface Arithmetic
{
    //public function sub($a, $b);
}

class Client
{
    
    public function computer(Arithmetic $arithmetic, $a, $b)
    {
        return $arithmetic->add($a, $b);
    }
}

class Addition implements Arithmetic
{
    public function add($a, $b)
    {
        return $a + $b;
    }
}

$c = new Client();
echo $c->computer(new Addition(), 2, 3);

/*
client 高层类 依赖于Arithmetic，Addition底层实现细节类实现Arithmetic接口，达到二者依赖于抽象接口的DIP设计原则
*/

登入後複製