Une introduction aux sept principes de la conception orientée objet en C#

1 : Principe de responsabilité unique (SRP)

1. Définition : Un objet ne doit contenir qu'une seule responsabilité, et la responsabilité est complètement encapsulée dans une classe

Ou : Dans la mesure du possible une classe est concernée, il ne devrait y avoir qu'une seule raison à son changement.

2. Analyse : Plus une classe (ou aussi grande qu'un module ou aussi petite qu'une méthode) porte de responsabilités, moins elle a de chances d'être réutilisée, et si une classe porte trop de responsabilités, elle sera tout à fait En raison du couplage de ces responsabilités, lorsqu'une des responsabilités change, cela peut affecter le fonctionnement des autres responsabilités. Les responsabilités d'une classe comprennent principalement deux aspects : les responsabilités en matière de données et les responsabilités comportementales se reflètent à travers ses attributs, tandis que les responsabilités comportementales se reflètent à travers ses méthodes. Le principe de responsabilité unique est une ligne directrice pour atteindre une cohésion élevée et un faible couplage. Il peut être trouvé dans de nombreuses techniques de refactorisation de code. C'est le principe le plus simple mais le plus difficile à appliquer. Il oblige les concepteurs à découvrir les différentes responsabilités des classes et à les séparer. découvrir les multiples responsabilités de la classe nécessite que les concepteurs aient de solides capacités d'analyse et de conception et une expérience de refactoring pertinente.

3. Exemple :

L'exemple montre que la « fonction de connexion » d'un système C/S basé sur Java est implémentée via la classe de connexion suivante (Login) :
Le seul le principe de responsabilité est désormais utilisé pour cela Refactor.

2 : Principe Ouvert-Fermé (OCP)

1. Définition : Une entité logicielle doit être ouverte aux extensions et fermée aux modifications. C'est-à-dire que lors de la conception d'un module, celui-ci doit être étendu sans être modifié, c'est-à-dire que le comportement du module peut être modifié sans modifier le code source.

2. Analyse : Le principe d'ouverture et de fermeture a été proposé par Bertrand Meyer en 1988. C'est l'un des principes les plus importants de la conception orientée objet. Dans la définition du principe ouvert-fermé, une entité logicielle peut faire référence à un module logiciel, à une structure partielle composée de plusieurs classes, ou à une classe indépendante. L'abstraction est la clé du principe ouvert/fermé. Le principe d'ouverture et de fermeture peut également être décrit par un « Principe d'Encapsulation de Variation » plus spécifique. Le Principe d'Encapsulation de Variation (EVP) nécessite de trouver les facteurs variables du système et de les encapsuler.

3 : Principe de substitution de Liskov (LSP)

1. Définition : Si pour chaque objet o1 de type S, il existe un objet o2 de type T, De sorte que le comportement de tous les programmes P défini avec T ne change pas lorsque tous les objets o1 sont remplacés par o2, alors le type S est un sous-type de type T

Ou : toutes les classes de base de référence (Classe parent) doivent pouvoir utiliser de manière transparente les objets de ses sous-classes .

2. Analyse : Le principe de substitution de Liskov a été développé par Barbara Liskov, lauréate du prix Turing 2008, première femme docteur en informatique aux États-Unis, professeur au MIT et professeur Jeannette Wing à l'Université Carnegie Mellon. . Proposé en 1994.

Le principe de substitution de Liskov peut être exprimé d'une manière populaire : si vous pouvez utiliser des objets de classe de base dans un logiciel, alors vous devez être capable d'utiliser ses objets de sous-classe. Si la classe de base est remplacée par ses sous-classes, le programme ne générera aucune erreur ni exception. L'inverse n'est pas vrai. Si une entité logicielle utilise une sous-classe, elle ne pourra peut-être pas utiliser la classe de base. Le principe de substitution de Liskov est l'un des moyens importants d'implémenter le principe d'ouverture et de fermeture. Étant donné que les objets de sous-classe peuvent être utilisés partout où des objets de classe de base sont utilisés, essayez d'utiliser des types de classe de base pour définir des objets dans le programme, puis utilisez-les au moment de l'exécution. . Déterminez son type de sous-classe et remplacez l'objet de classe parent par l'objet de sous-classe.

Quatre : Principe d'inversion de dépendance (DIP)

1 Définition : Les modules de haut niveau ne doivent pas dépendre de modules de bas niveau, ils doivent tous s'appuyer sur des abstractions. L'abstraction ne devrait pas dépendre des détails, les détails devraient dépendre de l'abstraction

Ou : Programme pour les interfaces, pas pour les implémentations. (Programme vers une interface, pas une implémentation.)

2. Analyse : le principe d'inversion des dépendances est la troisième colonne de Engineering Notebook écrite par Robert C. Martin pour "C++ Reporter" en 1996, et a ensuite été ajoutée. À son livre classique "Agile Software Development, Principles, Patterns, and Practices" publié en 2002.

En termes simples, le principe de l'inversion des dépendances signifie : le code doit dépendre de classes abstraites, et non de classes concrètes ; la programmation doit être destinée aux interfaces ou aux classes abstraites, plutôt qu'à la programmation de classes concrètes. La clé pour réaliser le principe d'ouverture et de fermeture est l'abstraction, et la mise en œuvre concrète est dérivée de l'abstraction. Si le principe d'ouverture et de fermeture est l'objectif de la conception orientée objet, alors le principe d'inversion de dépendance est la principale méthode de conception orientée objet.

L'un des moyens courants d'implémenter le principe d'inversion de dépendance consiste à utiliser des classes abstraites dans le code et à placer des classes concrètes dans le fichier de configuration.

Couplage entre classes

Relation de couplage zéro

Relation de couplage concrète

Relation de couplage abstraite

Le principe d'inversion de dépendance nécessite que le client Dépend de couplage abstrait Le couplage de manière abstraite est la clé du principe d'inversion de dépendance.

Injection de dépendances

Injection de constructeur : injectez des variables d’instance via le constructeur.

Injection Setter : injectez des variables d'instance via la méthode Setter.

Injection d'interface : injectez des variables d'instance via des méthodes d'interface.

5 : Principe de ségrégation des interfaces (ISP)

1. Définition : Le client ne doit pas s'appuyer sur des interfaces dont il n'a pas besoin. Notez que l'interface dans cette définition fait référence à une méthode définie.

Ou : Une fois qu'une interface est trop grande, il faut la diviser en interfaces plus petites. Le client utilisant l'interface n'a besoin que de connaître les méthodes qui lui sont liées.

2. Analyse : Le principe de l'isolation des interfaces fait référence à l'utilisation de plusieurs interfaces spécialisées au lieu d'utiliser une seule interface totale. Chaque interface doit assumer un rôle relativement indépendant, ni plus ni moins. Elle ne doit pas faire des choses qu'elle ne devrait pas faire, mais doit faire tout ce qui doit être fait.

(1) Une interface ne représente qu'un seul rôle, et chaque rôle a sa propre interface spécifique. Ce principe peut être appelé le « principe d'isolation des rôles ».

(2) L'interface fournit uniquement les comportements dont le client a besoin, c'est-à-dire les méthodes requises. Les comportements dont le client n'a pas besoin sont masqués. Le client doit disposer d'une interface distincte aussi petite que. possible au lieu de fournir une grande interface globale.

Lorsque vous utilisez le principe d'isolation d'interface pour diviser une interface, vous devez d'abord respecter le principe de responsabilité unique, définir un ensemble d'opérations liées dans une interface, et sous réserve d'une cohésion élevée, moins il y a de méthodes dans le Interface Mieux c'est. Vous pouvez utiliser des services personnalisés lors de la conception du système, c'est-à-dire fournir des interfaces de différentes largeurs pour différents clients, fournir uniquement les comportements dont les utilisateurs ont besoin et masquer les comportements dont les utilisateurs n'ont pas besoin.

Six : Principe de réutilisation composite (CRP), également connu sous le nom de principe de composition/réutilisation d'agrégats (CARP)

1. Définition : Utiliser autant que possible les objets par composition plutôt que par héritage pour parvenir à la réutilisation. (Favorisez la composition d'objets plutôt que l'héritage comme mécanisme de réutilisation.)

2. Analyse : Le principe de composition et de réutilisation fait référence à l'utilisation de certains objets existants dans un nouvel objet à travers des relations d'association (y compris des relations de combinaison et des relations d'agrégation) objets existants, en les intégrant à un nouvel objet ; le nouvel objet atteint l'objectif de réutiliser ses fonctions existantes en déléguant et en appelant des méthodes d'objets existants. En bref : utilisez autant que possible les relations de composition/agrégation et moins souvent l’héritage.

Dans la conception orientée objet, les conceptions et implémentations existantes peuvent être réutilisées dans différents environnements via deux méthodes de base, à savoir via des relations de composition/agrégation ou via l'héritage.
Héritage et réutilisation : simples à mettre en œuvre et faciles à étendre. Détruit l'encapsulation du système ; l'implémentation héritée de la classe de base est statique, ne peut pas être modifiée au moment de l'exécution et n'a pas suffisamment de flexibilité ; elle ne peut être utilisée que dans des environnements limités ; (Réutilisation "boîte blanche")

Réutilisation de composition/agrégation : le degré de couplage est relativement faible et les opérations des objets membres sont appelées de manière sélective ; cela peut être effectué dynamiquement au moment de l'exécution. (Réutilisation "boîte noire")
La combinaison/agrégation peut rendre le système plus flexible, réduire le couplage entre les classes, et les changements dans une classe ont relativement peu d'impact sur les autres classes, donc la combinaison/agrégation est généralement préférée pour réaliser la réutilisation. ; deuxièmement, considérez l'héritage.Lors de l'utilisation de l'héritage, vous devez suivre strictement le principe de substitution de Liskov pour aider à comprendre le problème et réduire la complexité, tandis que l'abus de l'héritage augmentera la difficulté et la complexité du système. nécessitent une utilisation prudente de la réutilisation de l'héritage.

Sept : Loi de Déméter (LoD), également connue sous le nom de principe du moindre savoir (LKP)

1 Définition :

(1) Ne parlez pas aux «étrangers». .» La définition anglaise est : Ne parlez pas à des inconnus.

(2) Communiquez uniquement avec vos amis directs. La définition anglaise est la suivante : parlez uniquement à vos amis immédiats.

(3) Chaque unité logicielle a une connaissance minimale des autres unités et est limitée aux unités logicielles qui sont étroitement liées à sa propre unité. La définition anglaise est la suivante : Chaque unité ne doit avoir qu'une connaissance limitée des autres unités : uniquement les unités "étroitement" liées à l'unité actuelle) un projet de recherche appelé "Demeter". En termes simples, la loi de Déméter signifie qu'une entité logicielle doit interagir le moins possible avec d'autres entités. De cette façon, lorsqu'un module est modifié, cela affectera le moins possible les autres modules et l'expansion sera relativement facile. Il s'agit d'une restriction de la communication entre les entités logicielles. Elle nécessite de limiter la largeur et la profondeur de la communication entre les entités logicielles.

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!