Distinction entre délégation, composition et agrégation (Java OO Design)
Je suis confronté à un problème persistant distinguant la délégation, la composition et l'agrégation les uns des autres, et identifiant les cas où il est préférable de les utiliser les uns par rapport aux autres.
J'ai consulté un Java OO livre d'analyse et de conception, mais ma confusion persiste. La principale explication est la suivante:
Délégation: Lorsque mon objet utilise la fonctionnalité d'un autre objet tel quel sans le changer.
Composition: Mon objet se compose d'autres objets qui à leur tour ne peuvent pas exister après que mon objet soit détruit-ordures récupérées.
Agrégation: Mon objet se compose d'autres objets qui peuvent vivre même après la destruction de mon objet.
Est-il possible d'avoir quelques exemples simples illustrant chaque cas et le raisonnement derrière eux? Comment ces exemples peuvent-ils être démontrés autrement que mon objet ayant simplement une référence à un autre objet (s)?
Votre objet ferait référence à un autre objet dans les trois cas. La différence réside dans le comportement et/ou le cycle de vie des objets référencés. Quelques exemples:
Composition: La maison contient une ou plusieurs pièces. La durée de vie de la chambre est contrôlée par House car elle n'existerait pas sans House.
Agrégation: maison de jouets construite à partir de blocs. Vous pouvez le démonter mais les blocs resteront.
Délégation: Votre patron vous a demandé de lui faire un café, vous avez plutôt fait faire un stagiaire pour vous. La délégation n'est pas un type d'association (comme le sont la composition/agrégation). Les deux derniers ont été discutés sur Stack Overflow plusieurs fois
Dans le commentaire, vous demandez comment l'implémentation différerait dans chaque cas, en observant que dans tous les cas, nous invoquons des méthodes sur les objets créés. Il est vrai que dans chaque cas, nous aurions un code tel que
myRoom.doWork();
myBlock.doWork();
myMinion.doWork();
mais les différences résident dans le cycle de vie et la cardinalité des objets associés.
Pour le Composant, les Pièces prennent naissance lors de la création de la Maison. Nous pourrions donc les créer dans le constructeur de la maison.
Dans le cas de l'Association (j'utiliserai Tire and Car), les voitures peuvent ajouter des pneus dans leur constructeur, mais plus tard, vous voudrez peut-être supprimer et changer les pneus. Vous avez donc également des méthodes telles que
removeTyre(FrontLeft)
addNewTyre(aTyre, BackRight)
Et il est fort probable que l'objet aTyre provienne d'une usine - nous ne l'avons new dans aucune des méthodes de la voiture.
Dans le cas de la délégation, vous pourriez même ne pas avoir de variable membre pour contenir le délégué
resourcingPool().getIntern().getCoffee(SkinnyLatte, workstation 7);
la relation entre les objets ne dure que tant que le stagiaire va chercher le café. Il revient ensuite au pool de ressources.
Délégation
public class A {
private B b = new B();
public void methodA() {
b.methodB();
}
}
Lorsque les clients de A appellent methodA, la classe A délègue l'appel à B's methodB.
Justification. La classe A expose les comportements qui appartiennent ailleurs. Cela peut se produire dans des langages à héritage unique où la classe A hérite d'une classe, mais ses clients ont besoin de comportements qui sont implémentés dans une classe différente. Étude approfondie .
Délégation hybride
public class A {
private B b = new B();
public void methodA() {
b.methodB( this );
}
}
La différence entre la délégation qui implique un transfert simple et la délégation qui se substitue à l'héritage est que l'appelé doit accepter un paramètre de l'appelant, illustré par:
b.methodB( this );
Justification. Permet aux instances de classe B d'utiliser les fonctionnalités disponibles à partir de la classe A, tout comme la classe B le ferait s'il héritait de la classe A-- mais sans héritage. Étude approfondie .
Composition
public class A {
private B b = new B();
public A() {
}
}
Une fois qu'il n'y a plus de références à une instance particulière de la classe A, son instance de la classe B est détruite.
Justification. Permet aux classes de définir des comportements et des attributs de manière modulaire. Étude approfondie .
Agrégation
public class A {
private B b;
public A( B b ) {
this.b = b;
}
}
public class C {
private B b = new B();
public C() {
A a = new A( this.b );
}
}
Une fois qu'il n'y a plus de références à une instance particulière de la classe A, son instance de la classe B ne sera pas détruite. Dans cet exemple, A et C doivent être récupérés pour que B soit détruit.
Justification. Permet aux instances de réutiliser des objets. Étude approfondie .
Démonstration sans références
Les noms donnés à ces motifs simples sont définis par leurs relations référentielles.
Votre livre explique assez bien alors laissez-moi élaborer et vous donner quelques exemples.
délégation: Lorsque mon objet utilise la fonctionnalité d'un autre objet tel quel sans le modifier.
Parfois, une classe peut logiquement avoir besoin d'être grande. Mais une grande classe n'est pas une bonne pratique de codage. Parfois aussi, certaines fonctionnalités d'une classe peuvent être implémentées de plusieurs manières et vous voudrez peut-être changer cela un certain temps.
class FeatureHolder {
void feature() {
// Big implementation of the feature that you dont want to put in the class Big
}
}
class Big {
private FeatureHolder FH = new FeatureHolder();
void feature() {
// Delegate to FeatureHolder.
FH.feature();
}
//.. Other features
}
Dans l'exemple ci-dessus, Big.feature () appelle la fonction de FH telle quelle sans la changer. De cette façon, la classe Big n'a pas besoin de contenir l'implémentation de la fonctionnalité (séparation du travail). De plus, feature () peut implémenter différemment par une autre classe comme "NewFeatureHolder" et Big peut choisir d'utiliser le nouveau support de fonctionnalité à la place.
composition: Mon objet se compose d'autres objets qui à leur tour ne peuvent pas exister une fois que mon objet a été éliminé.
agrégation: Mon objet se compose d'autres objets qui peuvent vivre même après que mon objet soit détruit.
Techniquement, la composition fait "partie de" et l'agrégation est une relation "se référer à". Vos bras font partie de vous. Si vous ne vivez plus, votre bras mourra aussi. Votre tissu ne fait pas partie de vous mais vous les avez; comme vous pouvez l'inviter, votre tissu ne vous accompagne pas.
En programmation, certains objets font partie d'un autre objet et ils n'ont aucune signification logique sans lui. Par exemple, un bouton est composé d'un cadre de fenêtre. Si un cadre est fermé, le bouton n'a plus de raison d'être autour (Composition). Un bouton peut faire référence à une base de données (comme pour recréer des données); lorsque le bouton est supprimé, la base de données peut toujours être présente (agrégation).
Désolé pour mon anglais, j'espère que cela aide
1) Délégation: exemple homme-conducteur-voiture. Un homme a acheté une voiture. Mais cet homme ne sait pas conduire la voiture. Il nommera donc un chauffeur qui sait conduire une voiture. La classe Man veut donc effectuer un transport en voiture. Mais il n'a pas la fonctionnalité d'interaction/compatibilité avec la voiture. Il utilise donc une classe compatible avec la voiture qui est un pilote compatible avec la classe homme. En supposant que le conducteur peut comprendre ce que l'homme dit
2) Composition: la simulation automobile est un exemple de routine. Pour faire bouger une voiture, la roue tourne. La classe de voiture utilisant la classe de roue fait tourner la fonction dans le cadre de sa fonction de déplacement, alors que la roue fait partie de la voiture.
3) Agrégation: voiture et sa couleur. L'objet de classe de voiture ferrari aura un objet de classe de couleur rouge. Mais l'objet de classe de couleur rouge peut être présent en tant que classe individuelle, lorsque la recherche utilisateur se produit avec une spécification de couleur rouge.