Combien de principes y a-t-il dans les modèles de conception ?
Categories:
Les premiers principes de conception de modèles résumés ne comptaient que 5, à savoir SOLID :
Principe de responsabilité unique (Single Responsibility Principle, SRP): une classe ne devrait avoir qu’une seule raison de changer, c’est-à-dire qu’une classe ne devrait avoir qu’une seule responsabilité.Principe ouvert/fermé (Open/Closed Principle, OCP): les entités logicielles (classes, modules, fonctions, etc.) devraient être ouvertes à l’extension, mais fermées à la modification, c’est-à-dire que les changements devraient être réalisés par extension, et non par modification du code existant.Principe de substitution de Liskov (Liskov Substitution Principle, LSP): les sous-types doivent être capables de remplacer leurs types de base, c’est-à-dire que les classes dérivées doivent pouvoir remplacer leurs classes de base sans affecter la correction du programme.Principe de séparation des interfaces (Interface Segregation Principle, ISP): les clients ne devraient pas être contraints de dépendre d’interfaces qu’ils n’utilisent pas. Les grandes interfaces devraient être divisées en interfaces plus petites et plus spécifiques, afin que les clients n’aient besoin de connaître que les méthodes qu’ils doivent utiliser.Principe d'inversion de dépendance (Dependency Inversion Principle, DIP): les modules de haut niveau ne devraient pas dépendre des modules de bas niveau ; les deux devraient dépendre d’abstractions. Les abstractions ne devraient pas dépendre des détails d’implémentation, et les détails d’implémentation devraient dépendre des abstractions.
Plus tard, deux règles ont été ajoutées. Ces règles ajoutées par la suite sont plus concrètes et plus directrices par rapport aux précédentes. Nous pouvons constater dans les explications des principes que SOLID décrit ce qu'il faut faire, tandis que les règles ajoutées décrivent ce qu'il faut faire en priorité/au mieux.
Principe de réutilisation par composition/agrégation (Composition/Aggregation Reuse Principle, CARP): il faut privilégier la composition (synthèse) et l’agrégation d’objets plutôt que l’héritage pour atteindre l’objectif de réutilisation du code.Loi de Démeter (Law of Demeter, LoD): un objet ne devrait connaître aussi peu que possible les autres objets, c’est-à-dire qu’un objet devrait savoir le moins possible sur la structure interne et les détails d’implémentation des autres objets.
Outre les principes de conception mentionnés ci-dessus, il existe d’autres principes de conception qui, bien qu’ils ne soient pas aussi largement connus que les précédents, ont également une importance directive pour la conception et l’architecture logicielles. Ces règles supplémentaires, proposées ultérieurement, semblent un peu superflues ; du moins, je pense qu’elles ne sont pas contraires à l’intuition et n’ont pas besoin d’une réflexion approfondie.
Principe du moindre savoir (Principle of Least Knowledge, PoLK): également connu comme une extension de la loi de Démeter, il affirme qu’un objet devrait connaître le moins possible d’informations sur les autres objets. Ce principe remonte à 1987, lorsqu’il a été proposé par Patricia Lago et Koos Visser sous le nom de « loi du moindre communication ».Principe de dépendance stable (Stable Dependencies Principle, SDP): ce principe stipule que la conception logicielle devrait garantir que les composants stables ne dépendent pas des composants instables, c’est-à-dire que les composants plus stables devraient dépendre moins des composants moins stables. Cette idée provient de recherches approfondies sur les relations entre les composants dans les systèmes logiciels.Principe d'abstraction stable (Stable Abstraction Principle, SAP): en écho au principe de dépendance stable, ce principe guide l’appariement de l’abstraction avec la stabilité, c’est-à-dire que les composants stables devraient être abstraits, tandis que les composants instables devraient être concrets. Ce principe aide à assurer la stabilité et la flexibilité des systèmes logiciels.