Différence d’implémentation entre l’agrégation et la composition dans Java
Je suis conscient des différences conceptuelles entre l'agrégation et la composition. Quelqu'un peut-il me dire la différence de mise en œuvre dans Java entre eux avec des exemples?
Composition
final class Car {
private final Engine engine;
Car(EngineSpecs specs) {
engine = new Engine(specs);
}
void move() {
engine.work();
}
}
Agrégation
final class Car {
private Engine engine;
void setEngine(Engine engine) {
this.engine = engine;
}
void move() {
if (engine != null)
engine.work();
}
}
Dans le cas de la composition, le moteur est complètement encapsulé par la voiture. Le monde extérieur n'a aucun moyen d'obtenir une référence au moteur. Le moteur vit et meurt avec la voiture. Avec l'agrégation, la voiture remplit également ses fonctions via un moteur, mais le moteur n'est pas toujours une partie interne de la voiture. Les moteurs peuvent être intervertis, voire complètement supprimés. Non seulement cela, mais le monde extérieur peut toujours avoir une référence au moteur, et le bricoler, que ce soit dans la voiture.
Je voudrais utiliser un exemple Nice UML.
Pris une université a 1 à 20 départements différents et chaque département a 1 à 5 professeurs. Il existe un lien de composition entre une université et ses départements. Il existe un lien d'agrégation entre un département et ses professeurs.
La composition est juste une forte concentration, si l'université est détruite, les départements doivent également être détruits. Mais nous ne devrions pas tuer les professeurs même si leurs départements respectifs disparaissent.
Dans Java:
public class University {
private List<Department> departments;
public void destroy(){
//it's composition, when i destroy a university I also destroy the departments. they cant live outside my university instance
if(departments!=null)
for(Department d : departments) d.destroy();
departments.clean();
departments = null;
}
}
public class Department {
private List<Professor> professors;
private University university;
Department(University univ){
this.university = univ;
//check here univ not null throw whatever depending on your needs
}
public void destroy(){
//It's aggregation here, we just tell the professor they are fired but they can still keep living
for(Professor p:professors)
p.fire(this);
professors.clean();
professors = null;
}
}
public class Professor {
private String name;
private List<Department> attachedDepartments;
public void destroy(){
}
public void fire(Department d){
attachedDepartments.remove(d);
}
}
Quelque chose autour de ça.
En termes simples:
La composition et l'agrégation sont des associations. Composition -> Forte relation Has-A Agrégation -> Faible relation Has-A.
Il y a une bonne explication dans l'URL donnée ci-dessous.
http://www.codeproject.com/Articles/330447/Understanding-Association-Aggregation-and-Composit
Vérifiez s'il vous plaît!!!
La différence est que toute composition est une agrégation et non l'inverse.
Fixons les termes. L'agrégation est un métaterm de la norme UML et signifie à la fois la composition et l'agrégation partagée, simplement nommées partagées . Trop souvent, il est mal nommé "agrégation". C'est mauvais, car la composition est aussi une agrégation. Si je comprends bien, vous voulez dire "partagé".
Plus loin du standard UML:
composite - Indique que la propriété est agrégée de manière composite, c'est-à-dire que l'objet composite est responsable de l'existence et du stockage des objets composés (pièces).
Ainsi, l'association Université à cathédrales est une composition, car cathedra n'existe pas hors Université (IMHO)
La sémantique précise de l'agrégation partagée varie selon le domaine d'application et le modélisateur.
Autrement dit, toutes les autres associations peuvent être dessinées en tant qu'agrégations partagées, si vous ne suivez que certains de vos principes ou de ceux de quelqu'un d'autre. Regardez aussi ici .
Un programme de composition simple
public class Person {
private double salary;
private String name;
private Birthday bday;
public Person(int y,int m,int d,String name){
bday=new Birthday(y, m, d);
this.name=name;
}
public double getSalary() {
return salary;
}
public String getName() {
return name;
}
public Birthday getBday() {
return bday;
}
///////////////////////////////inner class///////////////////////
private class Birthday{
int year,month,day;
public Birthday(int y,int m,int d){
year=y;
month=m;
day=d;
}
public String toString(){
return String.format("%s-%s-%s", year,month,day);
}
}
//////////////////////////////////////////////////////////////////
}
public class CompositionTst {
public static void main(String[] args) {
// TODO code application logic here
Person person=new Person(2001, 11, 29, "Thilina");
System.out.println("Name : "+person.getName());
System.out.println("Birthday : "+person.getBday());
//The below object cannot be created. A bithday cannot exixts without a Person
//Birthday bday=new Birthday(1988,11,10);
}
}
Nous devons d’abord parler de la différence entre Aggregation et Composition sur la même page.
L'agrégation est une association dans laquelle l'entité associée peut exister indépendamment de l'association. Par exemple, une personne peut être associée à une organisation mais elle peut avoir une existence indépendante dans le système.
tandis que
La composition fait référence à une situation où l'une des entités associées est fortement liée à l'autre et ne peut exister sans l'existence de l'autre. En fait, l'identité de cette entité est toujours associée à l'identité de l'autre objet. Par exemple, des roues dans une voiture.
Maintenant, l’agrégation peut simplement être réalisée en détenant une propriété d’une entité dans une autre comme ci-dessous:
class Person {
Organisation worksFor;
}
class Organisation {
String name;
}
class Main {
public static void main(String args[]) {
//Create Person object independently
Person p = new Person();
//Create the Organisation independently
Organisation o = new Organisation();
o.name = "XYZ Corporation";
/*
At this point both person and organisation
exist without any association
*/
p.worksFor = o;
}
}
Pour Composition, il est nécessaire que l'objet dépendant soit toujours créé avec l'identité de son objet associé. Vous pouvez utiliser une classe interne pour la même chose.
class Car {
class Wheel {
Car associatedWith;
}
}
class Main {
public static void main() {
//Create Car object independently
Car car = new Car();
//Cannot create Wheel instance independently
//need a reference of a Car for the same.
Car.Wheel wheel = car.new Wheel();
}
}
Veuillez noter que le même cas d'utilisation peut tomber sous agrégation/composition selon le scénario d'application. Par exemple, le cas Personne-Organisation peut devenir composition si vous développez une application pour des personnes travaillant dans une organisation et que la référence à une organisation est indispensable pour vous inscrire. De même, si vous maintenez l'inventaire de pièces d'une voiture, la relation voiture-roue peut être une agrégation.
Les deux types sont bien sûr des associations et ne sont pas vraiment mappés strictement à des éléments de langage comme celui-là. La différence réside dans l'objectif, le contexte et la manière dont le système est modélisé.
A titre d'exemple pratique, comparez deux types de systèmes différents avec des entités similaires:
Un système d'immatriculation de voiture qui garde principalement une trace des voitures, de leurs propriétaires, etc. Nous ne sommes pas intéressés ici par le moteur en tant qu'entité séparée, mais peut encore avoir des attributs liés au moteur, comme la puissance et le type de carburant. Ici, le moteur peut être une composite partie de l'entité voiture.
Un système de gestion d'atelier de réparation automobile qui gère les pièces de voiture, assure l'entretien et le remplacement des pièces, voire même les moteurs complets. Ici, nous pouvons même avoir des moteurs en stock et avoir besoin de les suivre séparément et indépendamment des voitures. Ici, le moteur peut être une partie agrégée de l'entité voiture.
La façon dont vous appliquez cela dans votre langue est une préoccupation mineure car à ce niveau, des éléments comme la lisibilité sont beaucoup plus importants.