Quand dois-je utiliser un motif de conception composite?
Je ne comprends pas quand utiliser un modèle de conception composite . Quels types d'avantages vais-je retirer de ce modèle de conception? J'ai visité ce site Web mais il ne me renseigne que sur la structure du modèle de conception et non sur les scénarios dans lesquels c'est utilisé. J'espère que cela sera bénéfique pour les programmeurs comme moi qui commencent à apprendre le design pattern.
Citant de Design Patterns ,
Utilisez le motif composite lorsque
- vous souhaitez représenter des hiérarchies partielles d'objets.
- vous voulez que les clients puissent ignorer la différence entre les compositions d'objets et les objets individuels. Les clients traiteront tous les objets de la structure composite de manière uniforme.
Un usage courant est celui utilisé comme exemple de motivation dans le livre, un système d'affichage de fenêtres graphiques qui peut contenir d'autres fenêtres et éléments graphiques tels que des images, du texte. Le composite peut être composé au moment de l'exécution et le code client peut manipuler tous les éléments sans se soucier de quel type il s'agit pour les opérations courantes telles que le dessin.
Un composite est un modèle qui est utile à tout moment où vous devrez peut-être traiter sélectivement un groupe d'objets qui font partie d'une hiérarchie comme "les mêmes" alors qu'ils sont en fait différents. En règle générale, les exemples utilisés parlent de traitement identique des feuilles et des nœuds, mais le modèle peut également être étendu à des listes hétérogènes.
Par exemple, envisagez une visite chez le médecin. Lorsque vous allez chez un médecin, diverses choses se produisent, vous voyez généralement une infirmière ou un assistant en premier, ils prennent votre température, etc. Ensuite, le médecin effectue un examen et établit des diagnostics. Ensuite, le médecin peut faire un traitement, mais souvent l'infirmière revient pour finir. Et différentes activités sont réalisées lors de la visite. Vous avez des observations comme le poids et la température. Mais un laboratoire, par exemple, sera un objet différent, car il nécessite souvent un échantillon qui peut ensuite être envoyé et les résultats doivent être enregistrés à une date ultérieure.
Nous avons donc un logiciel qui permet d'enregistrer tout cela et il créera généralement une sorte de hiérarchie avec des nœuds comme:
Rencontre:
Examen préalable
Examen
Traitement
et sous chacun de ces nœuds, vous aurez une variété d'entrées telles que diagnostic, observation, procédure de laboratoire, diagnostic, injection, etc.
Tout cela est bien beau, et vous vous retrouvez avec un enregistrement hiérarchique structuré, bien que très complexe, de la rencontre.
Supposons maintenant que vous devez générer la facturation. Soudain, vous êtes confronté à une exigence très différente. Votre dossier médical était nécessaire pour créer une image très précise de la rencontre. Si vous ne vous souciez pas de savoir qui a fait quoi ou dans quel ordre, en fait, vous ne vous souciez vraiment pas de ce qu'est une activité au-delà d'un code de facturation. Vous voulez simplement une liste unique d'activités facturables, c'est-à-dire des codes.
Non seulement ces informations sont intégrées dans un enregistrement, mais cet enregistrement est également très difficile à parcourir car il contient un grand nombre d'objets différents. Il est également variable dans la structure hiérarchique - si vous avez un clou dans la tête, ils peuvent sauter tout type de pré-examen, ou d'examen d'ailleurs et aller au traitement. Si vous allez retirer des points de suture, il se peut qu'il n'y ait pas d'examen préalable ni d'examen. Un physique annuel n'a aucun traitement. etc etc. Très difficile à énumérer ce type de graphe d'objet.
Un motif composite résout tout cela. Vous définissez une interface commune ou une classe de base pour tous les objets. Appelons cela "CareEntry". CareEntry a une propriété BillingCode. Maintenant, votre rencontre peut apparaître comme un simple conteneur avec uniquement des objets CareEntry à l'intérieur. Votre service de facturation peut maintenant simplement énumérer tout ce qui se trouve à l'intérieur sans avoir à vous soucier de savoir si quelque chose est un nœud (PreExam, Exam) par rapport à une feuille (température de poids), ou dans quel nœud l'objet se trouve (PreExam Exam, etc.) ou quel est le type réel de l'objet est (laboratoire, injection, etc.). Tout est également un CareEntry et traité de manière uniforme - Vous énumérez simplement tous les objets CareEntry dans une rencontre et collectez chacun qui a un code de facturation non nul et vous avez terminé. C'est aussi simple que ça.
Le modèle composite permet aux clients de traiter les objets individuels ainsi que les compositions (d'objets individuels) de manière uniforme.
Par exemple, en double-cliquant sur le dossier, il faut ouvrir le dossier. Le double du fichier doit être ouvert dans le programme correspondant.
Le fonctionnement est le même mais se comporte selon qu'il s'agit d'objets individuels ou de compositions
Interface commune pour les objets individuels et les objets composites
interface Data{
public void doubleClick();
}
Implémentation d'objet individuel
class File implements Data {
private String name;
public String getName() {
return name;
}
public void setName(String name) {
this.name = name;
}
@Override
public void doubleClick() {
System.out.println(this.getName()+" file is Opened in a Program ");
}
}
Implémentation composite
class Folder implements Data {
private String name;
public String getName() {
return name;
}
public void setName(String name) {
this.name = name;
}
private List<Data> folder = new ArrayList<Data>();
@Override
public void doubleClick() {
System.out.println(this.getName() + " folder is Opened");
for(Data data : folder) {
data.doubleClick();
}
}
public void add(Data data) {
folder.add(data);
}
public void remove(Data data) {
folder.remove(data);
}
}
Programme client
public class CompositePattern {
public static void main(String[] args) {
Folder f1 = new Folder();f1.setName("Folder 1");
Folder f2 = new Folder();f2.setName("Folder 2");
Folder f3 = new Folder();f3.setName("Folder 3");
File file1 = new File();file1.setName("File 1");
File file2 = new File();file2.setName("File 2");
File file3 = new File();file3.setName("File 3");
File file4 = new File();file4.setName("File 4");
f1.add(file1);
f2.add(file2);
f3.add(f2);
f3.add(file3);
f3.add(file4);
f1.doubleClick();f2.doubleClick();f3.doubleClick();
}
}
J'utilise souvent le modèle de conception composite pour masquer les collections. Dans de nombreux cas, nous travaillons avec des collections exactement de la même manière lorsqu'il y a de nombreux éléments et lorsqu'ils ne contiennent qu'un seul élément.
C'est le problème, car la classe contenant une collection fourmille ensuite de boucles foreach qui font essentiellement la même chose - parcourez tous les éléments et appliquez une fonction d'agrégation.
Pour résoudre le problème, j'introduis une interface qui est implémentée par l'élément unique ainsi que la classe cachant la collection de ces éléments. Le but de la classe composite est alors de contenir toutes les fonctions d'agrégation qui se trouvaient auparavant dans la classe client.
Vous pouvez trouver des exemples utiles dans cet article: Travailler avec des collections
La chose courante ici est que Composite ne représente pas nécessairement la relation partie-tout. Il est possible d'introduire un élément composite juste pour déplacer les boucles hors du client.
Et voici un exemple pratique d'application du motif composite pour masquer des pièces derrière l'élément composite: Motif de conception composite
Ayant récemment étudié et essayé, j'ai reconnu un concept puissant à garder à l'esprit à propos des composites.
Les composites cachent la complexité des collections, c'est-à-dire les parcourent, les trient, les filtrent, etc. et vous permettent de les traiter comme s'il s'agissait d'un seul organisme.
Dites, vous avez un chien dans un chenil et plusieurs chiens dans un autre. Vous voulez les nourrir et les vacciner, mais vous ne pouvez pas les nourrir s'ils ont mangé dans l'heure ou les nourrir s'ils ont été vaccinés au cours des cinq dernières heures, ou les vacciner s'ils ont vomi, etc.
Plus important encore, il y a des règles d'ordre d'emballage lorsque le chien de race A mange avant la race B, à moins que le chien de race C ne soit autour et aboie jusqu'au sommet de ses poumons.
Cela atteindra rapidement un point où vous ne voudrez plus vous soucier de rien, mais appelez simplement un assistant et dites-lui de nourrir "tous les chiens". Ou mieux, trois aides pour garder une trace de l'alimentation, de la vaccination et des vomissements, des aboiements et de l'emballage et de toutes les autres choses impressionnantes.
En appelant des assistants, vous vous êtes appuyé sur le modèle Composition. Vous allez simplement "nourrir" chaque chenil, que ce soit un chien ou un dix. Vous voulez juste que le chenil plein de chiens les trie eux-mêmes et comprenne comment ils se nourrissent, parce que vous avez trop de choses en main à la caisse.
Donc, pour vous, un chien est un IDog, qui nourrit (), aboie (), vomit () et GetVaccine (). Un chenil est également un chien, que vous appelez chenil. Vous avez terminé. Le chenil doit déterminer ce qu'il faut faire maintenant en interne. Il peut avoir un mécanisme de chronométrage pour suivre l'alimentation de chaque chien et d'autres temps de fonction corporelle. Tout est parfaitement encapsulé.
Vous le trouverez peut-être indispensable lorsque vous travaillerez avec binary trees ou autre complex data structures like list of lists of lists - etc ... alors, quand chaque élément (classe) implémente 1 interface, vous pouvez faire les mêmes méthodes sur 1 feuille ou sur un groupe entier - couper, ajouter, supprimer, déplacer ... quoi que vous ayez correctement mis en œuvre. C'est très utile et simple.
La réponse devrait être -
Composez des objets en arborescences pour représenter des hiérarchies de pièces entières. Composite permet aux clients de traiter les objets individuels et les compositions d'objets de manière uniforme.
- Composition récursive
- "Les répertoires contiennent des entrées, chacune pouvant être un répertoire."
- 1 à plusieurs "a une" dans la hiérarchie "est une"
copié à partir d'un forum.
Exemple de modèle de conception composite dans le monde réel, lorsque nous avons des chances d'avoir une instance de même type parent à l'intérieur ou de type composant.
Exemple: dans les systèmes d'échange de devises Ex1
Vous pourriez avoir une paire de devises croisées (AUD/EUR)= (AUD/USD et 1/(EUR/USD)) le point ici est votre Instrument (Cross) peut avoir deux Instruments (Direct) à l'intérieur.
Dans un autre exemple,
Un Instrument (Cross) et Instrument (Direct) et Instrument (Cross) qui peuvent être divisés pour remorquer Instrument (Direct). SGD/CZK = USD/SGD (Direct) et USD/CZK (Cross USD/SGD (Direct) et (1/EUR/USD) (Direct) et EUR/CZK (Direct)) ==
Le point ici est que vous continuez à diviser jusqu'à ce que vous ne trouviez pas toutes les paires de devises directes.
Ci-dessus peut être facilement mis en œuvre en utilisant le modèle de conception composite.
si vous souhaitez créer un objet similaire imbriqué, vous pouvez opter pour un modèle de conception composite, par exemple: en temps réel si vous souhaitez afficher l'arborescence pour l'employé de bureau en fonction de la hiérarchie
J'espère que cela exemple simple aide
Et, bien connu Composite UI Application Block est basé sur Composite Pattern.