J'ai vraiment une compréhension difficile et une agrégation. Dans le code ci-dessous, je voudrais savoir laquelle de l'instance de voiture suivante utilise la logique de composition ou la logique d'agrégation.
public class Engine { public Engine() { } } public class Car1 { public final Engine engine; public Car1() { engine = new Engine(); } } class Car2{ public Engine engine; public Car2(Engine engine) { this.engine = engine; } } class Car3{ public final Engine engine; public Car3(Engine engine) { this.engine = engine; } } class Car4{ Engine engine; public Car4(){ this.engine = new Engine(); } } class Main{ public static void main(String[] args) { Engine engine = new Engine(); Car1 car1 = new Car1(); Car2 car2_1 = new Car2(new Engine()); Car2 car2_2 = new Car2(engine); Car3 car3_1 = new Car3(new Engine()); Car3 car3_2 = new Car3(engine); Car4 car4_1 = new Car4(); } }
3 Réponses :
Ouais, le moteur existe toujours en dehors de l'instance CAR3_2, de sorte que devrait être une agrégation. P>
Je suppose en Java Les différences sont difficiles à voir comme pour tout objet que vous ne pouvez stocker que des références à certains emplacements du tas, alors que dans d'autres langages de programmation tels que C ++, vous pouvez choisir si un objet contient une référence à un autre objet vs un objet. une copie intégrée de cet objet. p>
Mais nous sommes en Java et regardons la vie de vie .... Si le moteur existe plus longtemps que la voiture dépend si une personne détient une référence à ce moteur. Toutes les voitures mais car4 ont un champ de moteur disponible au public, tout le monde pouvait simplement saisir et garder la référence et maintenir ainsi le moteur tout en jetant la voiture. P>
Je préférerais que Car4 ne pas avoir un package (par défaut) mais même un accès privé. Cela signifierait que personne ne devrait avoir accès à cette référence de ce moteur (à moins que cela soit divulgué ailleurs) et vous pourriez parler de la composition. P>
EDIT: relire de votre question et de votre code de code au bas, je pense que la question est de savoir comment ils sont construits. CAR1 et CAR4_1 sont livrés avec leurs propres moteurs implicitement créés et que personne ne prenne une référence, les voitures et les moteurs obtiennent des ordures recueillies en même temps. J'appellerais cette composition. P>
car2_1 et car3_1 se comportent de même bien que le moteur a été construit explicitement. Ils recevraient des ordures collectées avec leurs moteurs respectifs. Cela se comporte de la même manière mais permet également le prochain motif. Je suppose que cela a été introduit comme un leurre. P>
car2_2 et car3_22 Partagez un moteur explicitement créé et la référence à celle-ci est présente dans la méthode principale. L'une ou les deux voitures pourrait avoir des ordures collectées, mais le moteur resterait à moins que toutes les trois références soient abandonnées. Donc, cela devrait probablement montrer l'agrégation. P>
Agrégation forte> implique une relation où l'enfant peut exister indépendamment du parent. Exemple: classe (parent) et étudiant (enfant). Supprimer la classe et les étudiants existent toujours. Li> composition forte> implique une relation où l'enfant ne peut exister indépendamment du parent. Exemple: maison (parent) et chambre (enfant). Les chambres n'existent pas séparément à une maison. Li> ul> blockQuote> Donc, par cette nature même, il ne peut pas être composition em> pour tout objet qui: p>
- peut être
possédée forte> par plus d'un autre objet li> - peut être
unidsd fort> (après l'initialisation terminée) li> - peut
Changer le propriétaire strong> li> ul>
car3_2 code> ne peut pas être composition, car il partage le moteur avec
car2_2 code>. p>.
sont toutes les autres compositions? Logiquement parlant, dans véritable vie em>, vous pouvez retirer le moteur d'une voiture et l'installer dans une autre voiture, de sorte que la relation de moteur est donc une agrégation. P>
Programmatiquement, le mot-clé code> final (code> empêche le retrait d'un moteur code> dans la voiture code> code>, mais cela n'empêche pas le même moteur d'être ajouté à Une autre voiture, et elle n'empêche pas la voiture d'être "supprimée" et du moteur de changer de propriétaire, donc
final code> par lui-même n'assure pas une relation de composition. P>
Lorsque le constructeur prend le moteur en tant que paramètre, la classe
voiture code> ne peut pas s'assurer que le moteur n'est pas partagé, donc ne garantit pas une relation de composition. P>
uniquement lorsque le moteur code> est créé par le constructeur code> voiture code> et le champ est
final code> (ou efficacement-final, essentiellement
privé code> sans méthode de setter), est-il garanti que la définition de la composition est honorée. p>
ne signifie pas les autres, qui prennent code> le moteur code> en tant que paramètre, ne peut pas être composition efficace. Cela dépend de la façon dont il est utilisé. Par exemple. Si la voiture code> est créée par une classe code> usine code>, l'usine peut appliquer les règles de composition. P>
Dupliqué possible de Quelle est la différence entre l'association, l'agrégation et la composition?