Résumé des cinq principes de la conception orientée objet PHP (SOLID)-tutoriel php-php.cn

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

Copier après la connexion

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();

Copier après la connexion

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());

Copier après la connexion

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);

Copier après la connexion

总结

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设计原则
*/

Copier après la connexion