Une brève introduction aux concepts et principes de conception de OO en Java (Collection)

L'éditeur suivant vous proposera un article discutant brièvement du concept d'OO en Java et des principes de conception (à lire absolument). L'éditeur pense que c'est plutôt bien, alors je vais le partager avec vous maintenant et le donner comme référence. Suivons l'éditeur pour venir jeter un oeil

1. La base de conception de OO (Orienté objet)

Orienté objet (OO) : Elle est basée sur le concept d'objet, centré sur l'objet, la classe et héritagePour le mécanisme de construction, utiliser pleinement les interfaces et le polymorphisme pour offrir la flexibilité nécessaire pour reconnaître, comprendre, caractériser le monde objectif et concevoir et construire les systèmes logiciels correspondants. Fonctionnalités orientées objet : Bien que les différents langages de programmation orientés objet

soient différents les uns des autres, ils peuvent tous être considérés comme prenant en charge les fonctionnalités de base de l'orienté objet,

à savoir "l'abstraction , encapsulation, héritage, Polymorphisme » :

– Abstraction,
Ne considérez pas les détails d'abord – Encapsulation,
Masquer l'implémentation interne – Héritage,
Réutiliser le code existant– Polymorphisme, Réécrire l'objet comportement

Orienté objetModèle de conception

 : Il s'agit d'une "bonne conception orientée objet". La soi-disant "bonne conception orientée objet" est celle des conceptions qui peuvent " répondre aux changements et améliorer la réutilisation". Les modèles de conception orientés objet décrivent la conception de logiciels, ils sont donc indépendants des langages de programmation, mais la mise en œuvre finale des modèles de conception orientés objet doit toujours être exprimée à l'aide de langages de programmation orientés objet. Les modèles de conception orientés objet ne sont pas comme des techniques algorithmiques qui peuvent être copiées et utilisées. Il s'agit d'une compréhension empirique basée sur une compréhension compétente et approfondie de « l'orientation objet ».

Ce qui précède donne une description générale des concepts et des relations entre les modèles orientés objet et les modèles de conception. Lorsque nous concevons, nous comprenons et utilisons pleinement les quatre caractéristiques de base de l'OO pour développer la conception. Par conséquent, tout le monde doit connaître et maîtriser la technologie orientée objet avant de la concevoir. Je ne la présenterai pas en détail ici, mais pour les modèles de conception. fournissez-nous un modèle

de référence lors de la conception, et le prérequis pour maîtriser les modèles de conception orientés objet est d'abord de maîtriser la technologie « orientée objet ».

2. Objectifs de conception OO (orientés objet)

※Extensibilité :

Avec de nouvelles exigences, de nouvelles performances peuvent être facilement ajoutées Cela n'affectera pas le performances existantes ou introduire de nouveaux défauts dans le système.

※Flexibilité de modification : Lorsque le code d'une partie du système est modifié, cela ne détruira pas la structure existante du système et n'affectera pas autres

partie.

※Pluggabilité :

Certains codes du système peuvent être remplacés par d'autres classes de la même interface sans affecter le système.

3. Les cinq principes de la conception OO et leurs relations

3.1 Résumé des principes de conception OO

※Principe de responsabilité unique :

En ce qui concerne une classe, il ne devrait y avoir qu'une seule raison pour son changement. Le célibat est une bonne conception pour une classe. Des responsabilités mixtes et peu claires rendront le code particulièrement maladroit, affectant l'ensemble du corps, perdant en esthétique et entraînant inévitablement le risque d'erreurs système laides.

※Principe ouvert-fermé : signifie que les entités logicielles (classes, modules, fonctions , etc.) doivent être extensibles mais non modifiables . L'idée centrale de la réalisation du principe ouvert et fermé est de programmer de manière abstraite plutôt que concrète, car l'abstraction est relativement stable. Laissez la classe dépendre d'une abstraction fixe, de sorte que les modifications soient fermées ; et grâce à des mécanismes d'héritage et de polymorphisme orientés objet, vous pouvez hériter de la classe abstraite

et modifier le comportement inhérent en remplaçant ses méthodes. , donc c'est ouvert. "Les exigences changent constamment" et il n'y a pas de logiciel immuable, il est donc nécessaire d'utiliser le principe fermé et ouvert pour clôturer les modifications afin de répondre aux besoins, tout en maintenant la stabilité du système de packaging au sein du logiciel et en n'étant pas affecté par les changements dans exigences.

※Principe d'inversion des dépendances : Faire confiance à l'abstraction, ne pas se fier au concret. La stabilité de l'abstraction détermine la stabilité du système, car l'abstraction est immuable et la dépendance à l'égard de l'abstraction est l'essence de la conception orientée objet et le cœur du principe d'inversion de dépendance. S'appuyer sur l'abstraction est un principe général, mais parfois s'appuyer sur des détails est inévitable. Le compromis entre abstraction et caractère concret doit être pesé, et la méthode n'est pas statique. S'appuyer sur l'abstraction signifie programmer l'interface, pas l'implémentation.

※Le principe de substitution de Liskov : Les sous-types doivent pouvoir être remplacés par leur type parent. Le principe de substitution de Liskov se concentre principalement sur la construction de l'abstraction et du polymorphisme sur la base de l'héritage. Par conséquent, ce n'est qu'en suivant le principe de substitution de Liskov que la réutilisation de l'héritage peut être assurée de manière fiable. La méthode d'implémentation est une programmation orientée interface : abstrait la partie publique dans une interface de classe de base ou une classe abstraite, utilisez ExtractAbstractClass et implémentez de nouvelles méthodes dans la sous-classe en remplaçant le parent méthode de classe. manière de supporter les mêmes responsabilités. Le principe de substitution de Liskov peut garantir une bonne évolutivité du système tout en implémentant un mécanisme d'abstraction basé sur le polymorphisme, qui peut réduire la redondance du code et éviter la discrimination de type pendant l'exécution.

※Principe d'isolation des interfaces : Plusieurs interfaces liées au client valent mieux qu'une seule interface générale. Il existe deux méthodes principales de séparation : 1. Séparation par délégation, en ajoutant un nouveau type pour déléguer la demande du client, isolant ainsi la dépendance directe du client et de l'interface, mais cela augmentera la surcharge du système. 2. Séparez l'héritage multiple et répondez aux besoins des clients grâce à l'héritage multiple d'interface. Cette méthode est meilleure.

Voici deux principes qui n'ont pas été mentionnés auparavant et qui sont également des principes importants à prendre en compte lors de la conception.

※Loi de Demit : Ne pas interagir directement entre les classes qui ne communiquent pas directement entre elles. Si deux classes n’ont pas besoin de communiquer directement entre elles, alors elles ne doivent pas interagir directement. Si une classe doit appeler une méthode d’une classe, l’appel peut être transmis via un tiers. Le premier principe souligné par la loi de Déméter est que dans la conception des classes, chaque classe doit minimiser les droits d'accès des membres. Son idée fondamentale est de mettre l’accent sur le couplage lâche entre les classes.

※Synthèse/AgrégationPrincipe de réutilisation : Utilisez autant que possible la composition/agrégation et essayez de ne pas utiliser l'héritage. La composition (Composition) et l'agrégation (Agrégation) sont deux types particuliers d'association. L'agrégation représente une relation de propriété faible ; la composition est une relation de propriété forte, incarnant des parties et des touts stricts. même cycle de vie. Préférer les principes de composition ou d’agrégation aidera à garder chaque classe encapsulée et concentrée sur une seule tâche. De cette façon, les classes et les hiérarchies d'héritage de classes restent petites et sont moins susceptibles de devenir des monstres incontrôlables

3.2 Relation entre les principes de conception OO

1. L'étape clé pour réaliser le principe « ouvert-fermé » (OCP) est l'abstraction. La relation d'héritage entre les classes de base et les sous-classes est le reflet de l'abstraction. Par conséquent, le principe de substitution de Liskov est une spécification des étapes spécifiques pour réaliser l’abstraction. Violer le principe de substitution de Liskov signifie violer le principe « ouvert-fermé », mais pas nécessairement l'inverse.

2. Le principe « ouvert-fermé » et le principe d'inversion de dépendance (DIP) sont la relation entre les objectifs et les moyens. Si le principe d'ouverture et de fermeture est l'objectif, le principe d'inversion de dépendance est le moyen d'atteindre le principe d'ouverture et de fermeture. Si vous souhaitez obtenir le meilleur principe « d'ouverture et de fermeture », vous devez respecter autant que possible le principe d'inversion de dépendance. Le principe d'inversion de dépendance est la meilleure spécification pour « l'abstraction ».

3. Le principe de substitution de Liskov (LSP) est la base du principe d'inversion de dépendance, et le principe d'inversion de dépendance est un complément important au principe de substitution de Liskov.

4. Le principe de séparation des interfaces (ISP) est également un moyen important pour garantir le principe « ouvert-fermé ».

5. Concernant le principe de responsabilité unique (SRP), je pense personnellement qu'il est préférable d'essayer de le mettre en œuvre le plus possible. Plus la responsabilité est simple, plus il est facile de mettre en œuvre du « open- ». fermer" et substitution Liskov.

4. La relation entre les principes et les objectifs de conception OO

1. Extensibilité : Permet à une nouvelle classe avec la même interface de remplacer l'ancienne classe, C'est la réutilisation d'interfaces abstraites. Le client s'appuie sur une interface abstraite plutôt que sur une classe d'implémentation concrète, afin que cette classe concrète puisse être remplacée par d'autres classes concrètes sans affecter le client. Les principes suivants permettent l’évolutivité.

※Principe ouvert/fermé
※Principe de substitution de Richter
※Principe d'inversion de dépendance
※Principe de réutilisation de composition/agrégation

2. Flexibilité de modification : Les modules sont relativement indépendants et communiquent le moins possible. De cette façon, lorsqu’un module est modifié, cela aura peu d’impact sur les autres modules.

Les principes suivants permettent la modifiabilité.

※Principe ouvert/fermé
※Loi de Déméter
※Principe d'isolation de l'interface

3. ne répond plus aux besoins, l'ancienne pièce peut être retirée et la nouvelle pièce insérée. Les principes suivants permettent la remplaçabilité.

※Principe ouvert/fermé

※Principe de substitution de Richter

※Principe d'inversion de dépendance
※Principe de réutilisation de composition/agrégation

5 ． Processus de conception OO (orienté objet)

1. Analyser le style et classer les fonctions.

2. Classes abstraites basées sur des fonctions. ※ Abstraction de classe - Dans cette étape, nous pouvons effectuer une abstraction spécifique de la classe basée sur le « principe de responsabilité unique ». Essayez de rendre les fonctions de la classe simples et claires.

※ Points de changement d'encapsulation – Utilisez l'encapsulation pour

créer une couche limite entre les objets

, permettant aux concepteurs d'apporter des modifications d'un côté de la couche limite sans provoquer d'effets indésirables de l'autre côté, influençant ainsi obtenir un couplage lâche entre les couches.

3. Concevoir des classes de base abstraites et des classes d'interface. ※ Lors de l'abstraction de la classe de base de base et de la définition de l'interface, le « principe de séparation des interfaces » doit être suivi pour abstraire l'interface.

※ Lors de la conception d'interfaces et de classes de base, ne faites pas toujours attention aux détails. N'oubliez pas de programmer pour l'interface, pas pour l'implémentation.

※ Les exigences du « Principe de substitution de Richter » doivent être respectées entre les classes de base abstraites et les classes dérivées.

4. Déterminer la relation de couplage entre les classes.

4.1 Quelle est la base pour déterminer le degré de couplage ? ※ En termes simples, le degré de couplage est déterminé en fonction de la stabilité de la demande.

※ Pour les exigences de grande stabilité et les exigences qui ne sont pas faciles à modifier, nous pouvons complètement concevoir différents types pour qu'ils soient étroitement couplés, car cela peut améliorer l'efficacité, et nous pouvons également utiliser de meilleures technologies pour améliorer l'efficacité ou simplifier le code.

※ Si les exigences sont très susceptibles de changer, nous devons pleinement considérer le problème de couplage entre les classes. Nous pouvons proposer différentes façons de réduire le degré de couplage, mais en résumé, ce n'est rien de plus. croissant Le niveau d'abstraction permet d'isoler différentes classes. Ce niveau d'abstraction peut être une classe abstraite, une classe concrète, une interface ou un groupe de classes. Nous pouvons résumer l'idée de réduire le couplage en une phrase : "Programmation pour les interfaces, pas programmation pour l'implémentation.

※ Lors de la détermination de la relation de couplage des classes, essayez de considérer la "Loi de Dimiter" et la "Synthèse" / Principe de réutilisation d'agrégation".

4.2 Comment réaliser l'inversion de dépendance ? ※ Le couplage de manière abstraite est la clé de l'inversion de dépendance Les relations de couplage abstraites impliquent toujours des classes concrètes héritant de classes abstraites, et il est nécessaire de garantir que toute référence

à une classe de base peut être modifiée en sa sous-classe. Par conséquent, le principe de substitution de Liskov est le principe d'inversion de dépendance.

※ Dépend de l'abstraction : il est recommandé de ne pas s'appuyer sur des classes concrètes, c'est-à-dire que toutes les dépendances du programme doivent se terminer par des classes ou des interfaces abstraites :

.

(1) Aucune
variable

ne doit contenir un pointeur ou une référence à une classe concrète

(2) Aucune classe ne doit être dérivée d'une classe concrète. une classe concrète. Vous ne devez pas remplacer les méthodes implémentées dans aucune de ses classes de base

5 Utilisez les 5 principes de la conception OO pour optimiser davantage la conception

<.>※ Pour l'abstraction et les fonctions de la classe, si elle satisfait au « principe de responsabilité unique » ※ Pour les relations d'héritage et les références aux classes de base, si elle satisfait au « principe de substitution de Liskov » et à « l'inversion de dépendance » Principe" ※ Pour les interfaces et les classes de base, si le "principe d'isolation des interfaces" est respecté ※ Si le "principe d'ouverture-fermeture" est généralement satisfait

De manière générale, lors de la conception dans la conception orientée objet, il est nécessaire de prendre pleinement en compte les cinq grands principes de la conception, mais de ne pas insister là-dessus. La poursuite aveugle du principe de satisfaction peut également conduire à une consommation de performances et de ressources du système conçu. la conception peut être réalisée en fonction de la situation spécifique

.

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!