Explication graphique détaillée des principes de composition, d'agrégation et de réutilisation en Java

Cet article présente principalement les principes de synthèse, d'agrégation et de réutilisation. L'éditeur le trouve plutôt bien, je vais le partager avec vous maintenant et le donner comme référence. Suivons l'éditeur pour y jeter un œil

Principe de synthèse, d'agrégation et de réutilisation

Le principe de synthèse et de réutilisation est aussi appelé principe de combinaison/ agrégation et réutilisation (Principe de composition/agrégation de réutilisation (CARP), qui est défini comme suit :

Principe de réutilisation composite (CRP) : essayez d'utiliser une combinaison d'objets au lieu de l'héritage pour atteindre l'objectif de réutilisation.

Le principe de synthèse et de réutilisation est d'utiliser certains objets existants dans un nouvel objet à travers des relations d'association (y compris des relations de combinaison et des relations d'agrégation) pour les intégrer au nouvel objet ; L'objet atteint l'objectif de réutiliser des fonctions en appelant des méthodes d'objets existants par délégation. En bref : Lors de la réutilisation, essayez d'utiliser des relations de combinaison/agrégation (relations d'association) et utilisez moins d'héritage.

Dans la conception orientée objet, il existe deux manières de réutiliser les conceptions et implémentations existantes dans différents environnements, à savoir via des relations composition/agrégation ou via l'héritage, mais vous devez d'abord envisager d'utiliser la composition/agrégation, la combinaison /agrégation peut rendre le système plus flexible, réduire le couplage entre les classes, et les changements dans une classe auront relativement peu d'impact sur les autres classes. Deuxièmement, pensez à l'héritage. Lorsque vous utilisez l'héritage, vous devez suivre strictement les règles. La substitution, l'utilisation efficace de l'héritage aidera à comprendre le problème et à réduire la complexité, tandis que l'abus de l'héritage augmentera la difficulté de construction et de maintenance du système et la complexité du système. Par conséquent, la réutilisation de l'héritage doit être utilisée avec prudence.

Le principal problème de la réutilisation par héritage est que la réutilisation de l'héritage détruira l'encapsulation du système, car l'héritage exposera les détails d'implémentation de la classe de base à la sous-classe, car les détails internes de la classe de base sont généralement n'est pas visible pour la sous-classe, donc ce type de réutilisation est également appelé réutilisation « boîte blanche ». Si la classe de base change, alors l'implémentation de la sous-classe devra également changer ; et ne le fait pas. Il peut changer au moment de l'exécution et n'est pas assez flexible ; et l'héritage ne peut être utilisé que dans des circonstances limitées (par exemple, une classe n'est pas déclarée comme non héritable).

Extension

Pour une compréhension approfondie de l'héritage, vous pouvez vous référer à l'article de M. Wen Yu, l'auteur du livre "Conception d'architecture logicielle" - "Voir les montagnes n'est que des montagnes et voir l'eau n'est que de l'eau - Améliorer la compréhension de l'héritage".

Étant donné que la relation de combinaison ou d'agrégation peut incorporer des objets existants (également appelés objets membres) dans de nouveaux objets et les intégrer au nouvel objet, le nouvel objet peut appeler les fonctions des objets existants. les détails d'implémentation internes de l'objet membre sont invisibles pour le nouvel objet, donc ce type de réutilisation est également appelé réutilisation « boîte noire ». Par rapport à la relation d'héritage, son degré de couplage est relativement faible et les modifications dans l'objet membre n'ont aucun impact. sur le nouvel objet. L'impact n'est pas grand, et les opérations des objets membres peuvent être appelées de manière sélective dans de nouveaux objets en fonction des besoins réels. La réutilisation synthétique peut être effectuée dynamiquement au moment de l'exécution, et les nouveaux objets peuvent référencer dynamiquement d'autres objets du même type ; en tant qu'objets membres.

D'une manière générale, si la relation entre deux classes est "Has-A", la composition ou l'agrégation doit être utilisée, et s'il s'agit d'une relation "Is-A", l'héritage peut être utilisé . « Is-A » est une définition taxonomique stricte, ce qui signifie qu'une classe est « une sorte » d'une autre classe ; « Has-A » est différent, cela signifie qu'un certain rôle a une certaine responsabilité.

Ce qui suit est un exemple simple pour approfondir la compréhension du principe de synthèse et de réutilisation :

Dans la conception initiale du système CRM, les développeurs de Sunny Software Company ont pris en compte compte du petit nombre de clients. Le système utilise MySQL comme base de données. Les classes liées aux opérations de base de données telles que la classe CustomerDAO doivent se connecter à la base de données. La méthode getConnection() pour se connecter à la base de données est encapsulée dans la classe DBUtil. la méthode getConnection() de la classe DBUtil doit être réutilisée, le concepteur utilise CustomerDAO comme sous-classe A de la classe DBUtil, la structure du plan de conception initial est présentée dans la figure 1 :

Figure 1 Diagramme de structure du plan de conception initial

En tant que clients À mesure que le nombre augmente, le système décide de passer à la base de données Oracle, une nouvelle classe OracleDBUtil doit donc être ajoutée pour se connecter à la base de données Oracle. . Puisqu'il existe une relation d'héritage entre CustomerDAO et DBUtil dans le plan de conception initial, la classe CustomerDAO doit être modifiée lors du changement de méthode de connexion à la base de données. Le code source utilise CustomerDAO comme sous-classe d'OracleDBUtil, ce qui violera le principe d'ouverture-fermeture. . [Bien sûr, vous pouvez également modifier le code source de la classe DBUtil, ce qui violera également le principe d'ouverture et de fermeture. 】

Utilisez désormais le principe de synthèse et de réutilisation pour le reconstruire.

Selon le principe de composition et de réutilisation, nous devrions utiliser plus d'associations et moins d'héritage lors de la mise en œuvre de la réutilisation. Par conséquent, dans cet exemple, nous pouvons utiliser la réutilisation d'association pour remplacer la réutilisation d'héritage. La structure reconstruite est illustrée dans la figure 2 :

Figure 2 Structure reconstruite Image

.

Dans la figure 2, la relation entre CustomerDAO et DBUtil passe de l'héritage à l'association. L'injection de dépendances est utilisée pour injecter l'objet DBUtil dans CustomerDAO. Vous pouvez utiliser l'injection de constructeur ou l'injection Setter. Si vous devez étendre les fonctions de DBUtil, vous pouvez le faire via ses sous-classes, par exemple en vous connectant à la base de données Oracle via la sous-classe OracleDBUtil. Puisque CustomerDAO est programmé pour DBUtil, selon le principe de substitution Liskov, l'objet de la sous-classe DBUtil peut écraser l'objet DBUtil. Il vous suffit d'injecter l'objet de la sous-classe dans CustomerDAO pour utiliser les méthodes étendues par la sous-classe. Par exemple, en injectant l'objet OracleDBUtil dans CustomerDAO, la connexion à la base de données Oracle peut être réalisée. Le code d'origine n'a pas besoin d'être modifié et de nouvelles méthodes de connexion à la base de données peuvent être ajoutées de manière flexible.

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!