Résumé des cinq principes de la conception orientée objet PHP (SOLID)

Cet article présente principalement le résumé des cinq principes de la conception orientée objet PHP (SOLID), qui a une certaine valeur de référence. Maintenant, je le partage avec vous. Les amis dans le besoin peuvent s'y référer

PHP. principes de conception Pour faire le tri, reportez-vous à « Technologie de base PHP et meilleures pratiques », « Principes, modèles et pratiques de développement agile », à l'article Cinq principes de conception orientée objet PHP, Principes de modèle de conceptionSOLID

Responsabilité unique Principe, SRP)

Définition/Caractéristiques

• Une seule raison pour qu'une classe change

• Une classe n'en a qu'une responsabilité (Responsabilité : raison du changement)

• Éviter que les mêmes responsabilités soient réparties dans différentes classes et la duplication des fonctions

Problèmes

• Une classe a trop de responsabilités, et plusieurs responsabilités sont interdépendantes. Le changement d'une responsabilité affectera la capacité de cette classe à assumer d'autres responsabilités. Lorsque la cause du changement de classe se produira, elle en souffrira. conséquences inattendues. Détruire

Avantages de l'adhésion aux principes SPR

• Réduire le couplage entre les classes  : Lorsque les exigences changent, uniquement on est classe modifiée, isolant ainsi l'impact des changements sur les autres responsabilités

• Améliorant la réutilisabilité des classes : référence sur demande, une classe est responsable d'une responsabilité, exigences Les changements nécessitent uniquement de modifier la classe correspondante ou d'ajouter une certaine responsabilité

• Réduire la complexité de la classe : Responsabilité unique, fonctions décentralisées Réduire une classe à plusieurs classes de responsabilité Complexité

Exemple de code

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

Résumé

Une grande partie de ce que fait la conception logicielle consiste à découvrir les responsabilités et à les séparer raisonnablement. Si les modifications apportées à l’application affectent toujours plusieurs responsabilités en même temps, il n’est pas nécessaire de séparer les responsabilités.

Principe de ségrégation des interfaces FAI

Problème

Lors de la conception d'une application, l'interface de la classe n'est pas cohérente. Différents clients ne contiennent que quelques fonctions centralisées, mais le système forcera le client à implémenter toutes les méthodes du module et à écrire également des méthodes stupides. Une telle interface devient une grosse interface ou une pollution d'interface. Une telle interface introduira des comportements inappropriés dans le système, gaspillera des ressources, affectera d'autres programmes clients, améliorera le couplage, etc.

Définition/caractéristiques du FAI

• Les clients ne doivent pas être obligés de s'appuyer sur des méthodes/fonctions dont ils n'ont pas besoin

• La dépendance d'une classe sur une classe doit être basée sur la plus petite interface

• La classe d'implémentation de l'interface ne doit être présentée que comme le principe de responsabilité unique

Avantages de suivre le principe du FAI

• La séparation des interfaces sera importante, chaque groupe d'interfaces fournit des fonctions spécifiques pour servir un groupe spécifique de programmes clients

• Les modifications apportées à un groupe d'interfaces n'affecteront pas/légèrement autres interfaces/programme client pour garantir la pureté de l'interface

Solution

• L'interface Fat est décomposée en plusieurs interfaces spécifiques au client/plusieurs interfaces héritage séparé

• À l'aide de l'interface de séparation de délégation, deux objets participent au traitement de la même demande, et l'objet acceptant la demande délègue la demande à un autre objet pour traitement

Exemple de code

/*
* 公告接口
*/
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();

Résumé

Les classes Fat peuvent provoquer des relations de couplage anormales et nuisibles entre leurs programmes clients. En décomposant les clients lourds en plusieurs interfaces spécifiques au client, les clients dépendent étroitement des méthodes qu'ils appellent réellement, supprimant ainsi la dépendance entre les clients et les méthodes qu'ils n'appellent pas. L’isolation de l’interface doit rester petite et peu fréquente.

Comparaison entre SRP et ISP

• Les deux résolvent le principe de dépendance dans la conception de logiciels

• SRP se concentre sur la division des responsabilités , les classes de contraintes sont principalement des interfaces et des méthodes, qui sont les détails et l'implémentation dans le programme. Le FAI fait attention à l'isolement des interfaces. Ce qui est contraint, c'est l'interface, et la conception abstraite de l'interface se fait dans une perspective plus macro

Principe d'ouverture-fermeture OCP (Open- Fermer le principe OCP)

Problème

À mesure que l'échelle des systèmes logiciels continue de croître, la complexité de la maintenance et de la modification du système continue d'augmenter. Les modifications apportées à une partie du système affectent souvent d'autres modules. Une application correcte des principes OCP peut résoudre de tels problèmes.

Définition/Caractéristiques

• Un module doit être ouvert en termes d'extension de comportement et fermé en termes de variabilité

Suivre Avantages OCP

• Le comportement du module est extensible, et le comportement/fonction du module existant peut être facilement étendu

• Extensions du module le comportement n'aura pas/peu d'impact sur les systèmes/modules existants

Exemples de code

/*
* 定义有固定行为的抽象接口
*/
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());

Résumé

Idées de base d'OCP Il s'agit d'une programmation d'interface abstraite , et l'abstraction est relativement stable. Laissez les classes dépendre d'abstractions fixes, laissez les classes hériter des abstractions via l'héritage orienté objet et le polymorphisme, et écraser leurs méthodes ou comportements inhérents. Il s'agit de penser à de nouvelles méthodes/fonctions d'extension et de réaliser des extensions.

里氏替换原则（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设计原则
*/

总结

DIP原则就是每个高层次模块定义一个它所需服务的接口声明，低层次模块实现这个接口。每个高层次类通过该抽象接口使用服务。

思考

面向对象软件开发中合理的遵循设计原则可以更好的设计代码，减少不必要的错误，提高程序的可维护性，可扩展性和稳定性。

• 单一职责（SRP）如何正确的划分职责，类的职责单一提高代码复用性，降低耦合性

• 接口隔离（OCP）合理划分接口功能，保证接口的专一性，纯洁性，减少依赖关系

• 里氏替换（LSP）合理利用类的继承体系，保证真确的继承关系不被破坏

• 依赖倒置（DIP）抽象接口编程由于抽象具体实现

• 开放封闭（OCP）面向对象编程终极目标所达到的结果，类/模块/系统的功能行为可扩展，内部更改性是封闭的

以上就是本文的全部内容，希望对大家的学习有所帮助，更多相关内容请关注PHP中文网！

相关推荐：

对LNMP的运维追踪

对于PhpStorm代码格式化设置的介绍

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!