0
votes

Java Software Engineering: Composition VS Agrégation

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 :


0
votes

Ouais, le moteur existe toujours en dehors de l'instance CAR3_2, de sorte que devrait être une agrégation.


0 commentaires

0
votes

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.

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.

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.

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.

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.

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.


0 commentaires

0
votes
  • Agrégation 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.
  • composition 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.

    Donc, par cette nature même, il ne peut pas être composition pour tout objet qui:

    • peut être possédée par plus d'un autre objet
    • peut être unidsd (après l'initialisation terminée)
    • peut Changer le propriétaire

      car3_2 ne peut pas être composition, car il partage le moteur avec car2_2 . .

      sont toutes les autres compositions? Logiquement parlant, dans véritable vie , 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.

      Programmatiquement, le mot-clé final empêche le retrait d'un moteur dans la voiture , 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 par lui-même n'assure pas une relation de composition.

      Lorsque le constructeur prend le moteur en tant que paramètre, la classe voiture ne peut pas s'assurer que le moteur n'est pas partagé, donc ne garantit pas une relation de composition.

      uniquement lorsque le moteur est créé par le constructeur voiture et le champ est final (ou efficacement-final, essentiellement privé sans méthode de setter), est-il garanti que la définition de la composition est honorée.

      ne signifie pas les autres, qui prennent le moteur 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 est créée par une classe usine , l'usine peut appliquer les règles de composition.


0 commentaires