PHP オブジェクト指向設計 (SOLID) の 5 つの原則のまとめ-PHPチュートリアル-php.cn

この記事では、主に PHP オブジェクト指向設計 (SOLID) の 5 つの原則の概要を紹介しますが、これは一定の参考価値があります。ここで共有します。必要な友人は参考にしてください。

PHP設計原則これを整理するには、「PHP コアテクノロジとベストプラクティス」、「アジャイル開発の原則、パターン、およびプラクティス」の記事「PHP オブジェクト指向設計の 5 つの原則」、「デザインパターンの原則」を参照してください。SOLID

単一責任原則、SRP)

定義/機能

クラス変更の理由は 1 つだけです
クラスには、責任は 1 つ (責任: 変更の理由)
同じ責任が異なるクラスに分散されたり、機能が重複したりしないようにします

問題

クラスの責任が多すぎます。また、複数の責任が相互に依存しています。1 つの責任を変更すると、このクラスが他の責任を遂行する能力に影響します。クラス変更の原因が発生すると、クラスは変更されます。破壊

SPR 原則に従うことの利点

クラス間の結合を減らす: 要件が変化したとき、 1 つのクラスのみを変更することで、そのクラスに起因する他の責任への変更の影響を分離します。
クラスの再利用性を向上します: オンデマンドでの参照、1 つのクラスが責任を負います1 つの責任、要件に対して、変更には対応するクラスを変更するか、特定の責任を追加するだけで済みます。
クラスの複雑さを軽減します: 単一の責任、分散機能 1 つのクラスを削減します。複数の責任クラスへの複雑さ

コード例

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
    }
}

ログイン後にコピー

要約

ソフトウェア設計で行うことの多くは、責任を発見し、責任間の関係を合理的に分離することです。アプリケーションへの変更が常に複数の責任に同時に影響する場合、責任を分離する必要はありません。

インターフェイス分離原則 ISP

問題

アプリケーションを設計するとき、クラスのインターフェイスがまとまっていません。さまざまなクライアントにはいくつかの集中化された機能しか含まれていませんが、システムはクライアントにモジュール内のすべてのメソッドを実装することを強制し、いくつかのダムメソッドも作成します。このようなインターフェイスは、ファットインターフェイスまたはインターフェイス汚染になります。このようなインターフェイスは、システムに不適切な動作を導入し、リソースを浪費し、他のクライアントプログラムに影響を与え、結合を強化します。

ISP 定義/機能

クライアントは、必要のないメソッド/関数に依存することを強制されるべきではありません
##クラスに対するクラスの依存関係は、最小のインターフェイスに基づく必要があります。
インターフェイスの実装クラスは単一責任原則としてのみ提示する必要があります

#委任分離インターフェイスを使用すると、2 つのオブジェクトが同じリクエストの処理に参加し、リクエストを受け入れたオブジェクトがリクエストを別のオブジェクトに委任して処理します
コード例

/*
* 公告接口
*/
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 は責任の分割に重点を置いています, 主に Constraint クラスは実際にはインターフェイスとメソッドであり、プログラム内の詳細と実装です。 ISP はインターフェイスの分離に重点を置き、インターフェイスを制限し、よりマクロな観点からインターフェイスの設計を抽象化します
オープンクローズ原則 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设计原则
*/

ログイン後にコピー