SOLID : Partie 4 - Principe d'inversion de dépendance
PHPz
Libérer： 2023-09-01 19:50:01
original
1050 Les gens l'ont consulté
Responsabilité unique (SRP), Ouvert/Fermé (OCP), Substitution Liskov, Isolation d'interface et Inversion de dépendance. Cinq principes agiles qui devraient vous guider à chaque fois que vous écrivez du code.
Il serait injuste de vous dire qu’un principe SOLIDE est plus important qu’un autre. Cependant, aucun n’a peut-être un impact aussi direct et profond sur votre code que le principe d’inversion de dépendance, ou DIP en abrégé. Si vous trouvez d'autres principes difficiles à comprendre ou à appliquer, commencez par celui-ci, puis appliquez les principes restants au code qui suit déjà le DIP.
Définition
A. Les modules de haut niveau ne doivent pas dépendre des modules de bas niveau. Les deux devraient s’appuyer sur des abstractions.
B. Les abstractions ne devraient pas dépendre des détails. Les détails doivent dépendre de l'abstraction.
Ce principe a été défini par Robert C. Martin dans son livre « Agile Software Development, Principles, Patterns, and Practices » et ensuite republié en version C# dans le livre « Agile Principles, Patterns, and Practices in C# », qui est le dernier principe des cinq principes agiles SOLID.
DIP dans le monde réel
Avant de commencer à coder, je veux vous raconter une histoire. Chez Syneto, nous ne sommes pas toujours très prudents avec notre code. Il y a quelques années, nous en savions très peu et même si nous avons fait de notre mieux, tous les projets n'étaient pas aussi bons. Nous avons traversé l'enfer et en sommes revenus, et nous avons beaucoup appris par essais et erreurs.
Les principes SOLID et les principes de simplicité architecturale de l'oncle Bob (Robert C. Martin) ont changé la donne pour nous et ont changé notre façon de coder d'une manière difficile à décrire. En bref, je vais essayer d'illustrer certaines des décisions architecturales clés mises en œuvre par DIP qui ont eu un impact significatif sur notre projet.
La plupart des projets Web contiennent trois technologies principales : HTML, PHP et SQL. Peu importe la version spécifique de ces applications dont nous parlons ou le type d'implémentation SQL que vous utilisez. Le problème est que les informations du formulaire HTML doivent se retrouver d’une manière ou d’une autre dans la base de données. Le lien entre les deux peut être fourni par PHP.
Le plus important est que ces trois technologies représentent très bien trois couches architecturales différentes : l'interface utilisateur, la logique métier et la persistance. Nous discuterons plus tard de la signification de ces couches. Concentrons-nous maintenant sur quelques solutions étranges mais souvent rencontrées pour faire fonctionner ces technologies ensemble.
Plusieurs fois, j'ai vu des projets utiliser du code SQL dans des balises PHP à l'intérieur de fichiers HTML, ou du code PHP faisant écho à la page HTML et interprétant directement les variables globales $_GET 或 $_POST. Mais pourquoi est-ce mauvais ?
L'image ci-dessus représente la version originale que nous avons décrite dans le paragraphe précédent. Les flèches représentent diverses dépendances et nous pouvons conclure que fondamentalement tout dépend de tout. Si nous devons apporter des modifications à une table de base de données, nous pouvons finir par éditer le fichier HTML. Ou, si nous modifions un champ dans le code HTML, nous pourrions finir par modifier les noms de colonnes dans l'instruction SQL. Ou si nous regardons le deuxième modèle, si le HTML change, nous devrons très probablement modifier le PHP, ou dans un très mauvais cas, lorsque nous générons tout le contenu HTML à partir du fichier PHP, nous devrons certainement changer le fichier PHP pour modifier le contenu HTML. Il ne fait donc aucun doute que les dépendances entre classes et modules sont tortueuses. Mais cela ne s'est pas arrêté là. Peut stocker des procédures ; du code PHP dans des tables SQL.
Dans le schéma ci-dessus, la requête sur la base de données SQL renvoie le code PHP généré à l'aide des données de la table. Ces fonctions ou classes PHP exécutent d'autres requêtes SQL qui renvoient du code PHP différent, et la boucle continue jusqu'à ce que toutes les informations soient récupérées et renvoyées... éventuellement vers l'interface utilisateur.
Je sais que cela peut paraître scandaleux pour beaucoup d’entre vous, mais si vous n’avez pas été impliqué dans un projet inventé et mis en œuvre de cette manière, vous le ferez certainement dans votre future carrière. La plupart des projets existants, quel que soit le langage de programmation, sont écrits sur la base d'anciens principes, par des programmeurs qui s'en moquent ou ne savent pas comment mieux faire les choses. Si vous lisez ces tutoriels, il y a de fortes chances que vous ayez déjà atteint un niveau supérieur. Vous êtes prêt, ou prêt, à respecter votre profession, à adopter votre métier et à le faire mieux.
L’alternative est de répéter les erreurs de ceux qui vous ont précédé et d’en subir les conséquences. Chez Syneto, lorsqu’un de nos projets a atteint un état presque impossible à maintenir en raison de son architecture ancienne et interdépendante et que nous avons dû l’abandonner définitivement, nous avons décidé de ne plus emprunter cette voie. Depuis, nous nous efforçons d'avoir une architecture propre qui respecte correctement les principes SOLID et surtout le principe d'inversion de dépendances.
La magie de cette architecture réside dans la façon dont les dépendances sont pointées :
L'interface utilisateur (dans la plupart des cas le framework Web MVC) ou tout autre mécanisme de livraison du projet dépendra de la logique métier. La logique métier est assez abstraite. L'interface utilisateur est très spécifique. L'interface utilisateur n'est qu'un détail d'un projet et elle change beaucoup. Rien ne devrait dépendre de l'interface utilisateur, rien ne devrait dépendre de votre framework MVC.
Une autre observation intéressante que nous pouvons faire est la persistance, la base de données, MySQL ou PostgreSQL, selon la logique métier. Votre logique métier est indépendante de la base de données. Cela permet d'échanger la persistance si vous le souhaitez. Si demain vous souhaitez remplacer MySQL par PostgreSQL ou simplement par des fichiers texte brut, vous pouvez le faire. Bien entendu, vous devez implémenter une couche de persistance spécifique pour la nouvelle méthode de persistance, mais vous n'avez pas besoin de modifier une seule ligne de code dans votre logique métier. Le sujet de la persistance est expliqué plus en détail dans le didacticiel Évolution vers une couche de persistance.
Enfin, sur le côté droit de la logique métier, en dehors de celle-ci, nous avons toutes les classes qui créent les classes de logique métier. Ce sont les usines et classes créées par le point d’entrée de notre application. Beaucoup de gens ont tendance à penser que ceux-ci appartiennent à la logique métier, mais lorsqu’ils créent des objets métier, leur seule raison est de le faire. Ce ne sont que des classes qui nous aident à créer d'autres classes. Les objets métier et la logique qu'ils fournissent sont indépendants de ces usines. Nous pouvons fournir une logique métier en utilisant différents modèles comme une usine simple, une usine abstraite, un constructeur ou une création d'objet simple. Cela n'a pas d'importance. Une fois les objets métier créés, ils peuvent faire leur travail.
Afficher le code
Appliquer le principe d'inversion de dépendance (DIP) au niveau architectural est très simple si vous respectez les modèles de conception agiles classiques. Il est également facile et même amusant de pratiquer et de donner des exemples de logique métier. Nous allons imaginer une application de lecture de livres électroniques.
class Test extends PHPUnit_Framework_TestCase {
function testItCanReadAPDFBook() {
$b = new PDFBook();
$r = new PDFReader($b);
$this->assertRegExp('/pdf book/', $r->read());
}
}
class PDFReader {
private $book;
function __construct(PDFBook $book) {
$this->book = $book;
}
function read() {
return $this->book->read();
}
}
class PDFBook {
function read() {
return "reading a pdf book.";
}
}
Copier après la connexion
Nous avons commencé à développer la liseuse en un lecteur PDF. Jusqu'ici, tout va bien. Nous avons une vérification d'expression régulière pour vérifier cela en utilisant la partie clé de la chaîne renvoyée par la méthode PDFBook 的 PDFReader 类。读者上的 read() 函数委托给本书的 read() 方法。我们只是通过在 PDFBook 的 reader().
N'oubliez pas que ce n'est qu'un exemple. Nous n'implémenterons pas de logique de lecture pour les fichiers PDF ou d'autres formats de fichiers. C'est pourquoi notre test ne vérifiera que quelques chaînes de base. Si nous devions écrire une vraie application, la seule différence résiderait dans la manière dont nous testons les différents formats de fichiers. La structure des dépendances est très similaire à notre exemple.
拥有一个使用 PDF 书籍的 PDF 阅读器对于有限的应用程序来说可能是一个合理的解决方案。如果我们的范围是编写一个 PDF 阅读器，仅此而已，那么它实际上是一个可以接受的解决方案。但我们想编写一个通用的电子书阅读器，支持多种格式，其中我们第一个实现的版本是 PDF。让我们重命名我们的读者类。
class Test extends PHPUnit_Framework_TestCase {
function testItCanReadAPDFBook() {
$b = new PDFBook();
$r = new EBookReader($b);
$this->assertRegExp('/pdf book/', $r->read());
}
}
class EBookReader {
private $book;
function __construct(PDFBook $book) {
$this->book = $book;
}
function read() {
return $this->book->read();
}
}
class PDFBook {
function read() {
return "reading a pdf book.";
}
}
Copier après la connexion
重命名没有功能上的反作用。测试仍在通过。
测试于下午 1:04 开始...
PHPUnit 3.7.28 由 Sebastian Bergmann 编写。
时间：13 毫秒，内存：2.50Mb
好的（1 个测试，1 个断言）
进程已完成，退出代码为 0
但它具有严重的设计效果。
我们的读者变得更加抽象。更一般。我们有一个通用的 EBookReader，它使用非常具体的书籍类型 PDFBook。抽象取决于细节。我们的书是 PDF 类型这一事实应该只是一个细节，任何人都不应该依赖它。
class Test extends PHPUnit_Framework_TestCase {
function testItCanReadAPDFBook() {
$b = new PDFBook();
$r = new EBookReader($b);
$this->assertRegExp('/pdf book/', $r->read());
}
}
interface EBook {
function read();
}
class EBookReader {
private $book;
function __construct(EBook $book) {
$this->book = $book;
}
function read() {
return $this->book->read();
}
}
class PDFBook implements EBook{
function read() {
return "reading a pdf book.";
}
}
class Test extends PHPUnit_Framework_TestCase {
function testItCanReadAPDFBook() {
$b = new PDFBook();
$r = new EBookReader($b);
$this->assertRegExp('/pdf book/', $r->read());
}
function testItCanReadAMobiBook() {
$b = new MobiBook();
$r = new EBookReader($b);
$this->assertRegExp('/mobi book/', $r->read());
}
}
interface EBook {
function read();
}
class EBookReader {
private $book;
function __construct(EBook $book) {
$this->book = $book;
}
function read() {
return $this->book->read();
}
}
class PDFBook implements EBook {
function read() {
return "reading a pdf book.";
}
}
class MobiBook implements EBook {
function read() {
return "reading a mobi book.";
}
}
Nous devons nous efforcer de structurer notre code autour de ces chiffres, et il existe plusieurs techniques qui peuvent nous aider à y parvenir. Les fonctions doivent avoir une longueur maximale de quatre lignes (cinq lignes en incluant la ligne de définition) afin qu'elles puissent tenir dans nos têtes en même temps. La profondeur d'indentation ne dépasse pas cinq couches. Cours avec pas plus de neuf méthodes. Généralement, cinq à neuf classes de modèles de conception sont utilisées. Notre conception de haut niveau dans le modèle ci-dessus utilise quatre à cinq concepts. Il existe cinq principes SOLID, chacun nécessitant entre cinq et neuf sous-concepts/modules/classes pour être illustrés. La taille idéale d’une équipe de programmation est de cinq à neuf personnes. Le nombre idéal d’équipes dans une entreprise est de cinq à neuf.
Comme vous pouvez le constater, le chiffre magique sept, plus ou moins deux, est tout autour de nous, alors pourquoi votre code devrait-il être différent ?
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!
Le contenu de cet article est volontairement contribué par les internautes et les droits d'auteur appartiennent à l'auteur original. Ce site n'assume aucune responsabilité légale correspondante. Si vous trouvez un contenu suspecté de plagiat ou de contrefaçon, veuillez contacter admin@php.cn
![[Web front-end] Démarrage rapide de Node.js](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
