Ik ben me bewust van de conceptuele verschillen tussen aggregatie en compositie. Kan iemand me het implementatieverschil in Java tussen hen vertellen met voorbeelden?
Antwoord 1, autoriteit 100%
Compositie
final class Car {
private final Engine engine;
Car(EngineSpecs specs) {
engine = new Engine(specs);
}
void move() {
engine.work();
}
}
Aggregatie
final class Car {
private Engine engine;
void setEngine(Engine engine) {
this.engine = engine;
}
void move() {
if (engine != null)
engine.work();
}
}
In het geval van compositie wordt de motor volledig ingekapseld door de auto. Er is geen manier voor de buitenwereld om een verwijzing naar de Engine te krijgen. De motor leeft en sterft met de auto. Bij aggregatie vervult de auto zijn functies ook via een motor, maar de motor is niet altijd een intern onderdeel van de auto. Motoren kunnen worden verwisseld of zelfs volledig worden verwijderd. Niet alleen dat, maar de buitenwereld kan nog steeds een verwijzing naar de motor hebben en eraan sleutelen, ongeacht of deze zich in de auto bevindt.
Antwoord 2, autoriteit 9%
Ik zou een mooi UML-voorbeeld gebruiken.
Neem een universiteit met 1 tot 20 verschillende afdelingen en elke afdeling heeft 1 tot 5 professoren.
Er is een compositiekoppeling tussen een universiteit en haar afdelingen.
Er is een aggregatiekoppeling tussen een afdeling en haar professoren.
Samenstelling is slechts een STERKE aggregatie, als de universiteit wordt vernietigd, moeten de afdelingen ook worden vernietigd. Maar we moeten de professoren niet vermoorden, zelfs niet als hun respectievelijke afdelingen verdwijnen.
In 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);
}
}
Iets hieromtrent.
EDIT: een voorbeeld zoals gevraagd
public class Test
{
public static void main(String[] args)
{
University university = new University();
//the department only exists in the university
Department dep = university.createDepartment();
// the professor exists outside the university
Professor prof = new Professor("Raoul");
System.out.println(university.toString());
System.out.println(prof.toString());
dep.assign(prof);
System.out.println(university.toString());
System.out.println(prof.toString());
dep.destroy();
System.out.println(university.toString());
System.out.println(prof.toString());
}
}
Universiteitsklas
import java.util.ArrayList;
import java.util.List;
import java.util.stream.Collectors;
public class University {
private List<Department> departments = new ArrayList<>();
public Department createDepartment() {
final Department dep = new Department(this, "Math");
departments.add(dep);
return dep;
}
public void destroy() {
System.out.println("Destroying university");
//it's composition, when I destroy a university I also destroy the departments. they cant live outside my university instance
if (departments != null)
departments.forEach(Department::destroy);
departments = null;
}
@Override
public String toString() {
return "University{\n" +
"departments=\n" + departments.stream().map(Department::toString).collect(Collectors.joining("\n")) +
"\n}";
}
}
afdelingsklasse
import java.util.ArrayList;
import java.util.List;
import java.util.stream.Collectors;
public class Department {
private final String name;
private List<Professor> professors = new ArrayList<>();
private final University university;
public Department(University univ, String name) {
this.university = univ;
this.name = name;
//check here univ not null throw whatever depending on your needs
}
public void assign(Professor p) {
//maybe use a Set here
System.out.println("Department hiring " + p.getName());
professors.add(p);
p.join(this);
}
public void fire(Professor p) {
//maybe use a Set here
System.out.println("Department firing " + p.getName());
professors.remove(p);
p.quit(this);
}
public void destroy() {
//It's aggregation here, we just tell the professor they are fired but they can still keep living
System.out.println("Destroying department");
professors.forEach(professor -> professor.quit(this));
professors = null;
}
@Override
public String toString() {
return professors == null
? "Department " + name + " doesn't exists anymore"
: "Department " + name + "{\n" +
"professors=" + professors.stream().map(Professor::toString).collect(Collectors.joining("\n")) +
"\n}";
}
}
Professor Class
import java.util.ArrayList;
import java.util.List;
public class Professor {
private final String name;
private final List<Department> attachedDepartments = new ArrayList<>();
public Professor(String name) {
this.name = name;
}
public void destroy() {
}
public void join(Department d) {
attachedDepartments.add(d);
}
public void quit(Department d) {
attachedDepartments.remove(d);
}
public String getName() {
return name;
}
@Override
public String toString() {
return "Professor " + name + " working for " + attachedDepartments.size() + " department(s)\n";
}
}
De implementatie is debatabel omdat het afhangt van hoe u omgaan met het maken van creatie, het inhuren van verwijdering enz. Onbetrouwbaar voor het OP
Antwoord 3, Autoriteit 2%
Een eenvoudig samenstellingsprogramma
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);
}
}
Antwoord 4, autoriteit 2%
In eenvoudige bewoordingen:
Zowel Samenstelling als Aggregatie zijn associaties.
Samenstelling -> Sterke Has-A-relatie
Aggregatie -> Zwakke Has-A-relatie.
Antwoord 5, autoriteit 2%
Er staat een goede uitleg in de onderstaande url.
http://www.codeproject.com/Articles /330447/Understanding-Association-Aggregation-and-Composit
Controleer a.u.b.!!!
Antwoord 6, autoriteit 2%
Eerst moeten we het hebben over wat eigenlijk het verschil tussen Aggregationen Compositionis om op dezelfde pagina te staan.
Aggregatie is een associatie waarbij de geassocieerde entiteit onafhankelijk van de associatie kan bestaan. Een persoon kan bijvoorbeeld zijn gekoppeld aan een organisatie, maar hij/zij kan een onafhankelijk bestaan in het systeem hebben.
terwijl
Samenstelling verwijst naar een situatie waarin een van de geassocieerde entiteiten sterk gerelateerd is aan de ander en niet kan bestaan zonder het bestaan van de ander. In feite wordt de identiteit van die entiteit altijd geassocieerd met de identiteit van het andere object. Bijvoorbeeld wielen in een auto.
Aggregatie kan nu eenvoudig worden bereikt door een eigenschap van de ene entiteit in een andere te houden, zoals hieronder:
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;
}
}
Voor Composition is het noodzakelijk dat het afhankelijke object altijd wordt gemaakt met de identiteit van het bijbehorende object. Je kunt hiervoor een innerlijke klas gebruiken.
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();
}
}
Houd er rekening mee dat dezelfde use-case onder aggregatie/compositie kan vallen, afhankelijk van het toepassingsscenario. De casus Persoon-Organisatie kan bijvoorbeeld compositie worden als u een applicatie ontwikkelt voor mensen die in een organisatie werken en de verwijzing naar organisatie een must is om u aan te melden. Evenzo, als u inventaris bijhoudt voor delen van een auto, kan de relatie tussen auto en wiel aggregatie zijn.
Antwoord 7
Het verschil is dat elke compositie een aggregatie is en niet andersom.
Laten we de voorwaarden bepalen. De aggregatie is een metaterm in de UML-standaard en betekent zowel samenstelling als gedeelde aggregatie, eenvoudigweg gedeeldgenoemd. Te vaak wordt het ten onrechte “aggregatie” genoemd. Het is SLECHT, want compositie is ook een aggregatie. Zoals ik begrijp, bedoel je “gedeeld”.
Verder van de UML-standaard:
composiet – Geeft aan dat de eigenschap samengesteld is,
d.w.z. het samengestelde object is verantwoordelijk voor het bestaan en
opslag van de samengestelde objecten (delen).
Dus, University to cathedras-associatie is een compositie, omdat cathedra niet bestaat buiten University (IMHO)
De precieze semantiek van gedeelde aggregatie verschilt per toepassingsgebied en
modelleur.
Dat wil zeggen, alle andere associaties kunnen worden opgesteld als gedeelde aggregaties, als u slechts enkele principes van uzelf of van iemand anders volgt. Kijk ook hier.
Antwoord 8
Aggregatie versus compositie
Aggregatieimpliceert een relatie waarbij het kindonafhankelijk van de ouder kan bestaan. Bijvoorbeeld Bank en werknemer, verwijder de bank en de werknemer bestaat nog steeds.
terwijl Samenstellingeen relatie impliceert waarbij het kind niet kan bestaanonafhankelijk van de ouder. Voorbeeld: Mens en hart, hart bestaan niet los van een Mens.
Aggregatierelatie is “has-a”en compositie is “onderdeel van” relatie.
Samenstellingis een sterke associatie, terwijl aggregatie een zwakke associatie is.
Antwoord 9
Beide typen zijn natuurlijk associaties en niet echt strikt toegewezen aan dergelijke taalelementen. Het verschil zit in het doel, de context en hoe het systeem is gemodelleerd.
Vergelijk als praktisch voorbeeld twee verschillende soorten systemen met vergelijkbare entiteiten:
-
Een autoregistratiesysteemdat voornamelijk auto’s en hun eigenaren, enz. bijhoudt. Hier zijn we niet geïnteresseerd in de motor als een afzonderlijke entiteit, maar we hebben mogelijk nog steeds motorgerelateerde kenmerken, zoals vermogen en type brandstof. Hier kan de motor een samengesteldonderdeel zijn van de auto-entiteit.
-
Een beheersysteem voor autoservicewinkelsdat auto-onderdelen beheert, auto’s onderhoudt en onderdelen vervangt, misschien complete motoren. Hier hebben we misschien zelfs motoren op voorraad en moeten we deze en andere onderdelen apart en onafhankelijk van de auto’s bijhouden. Hier kan de motor een geaggregeerdonderdeel zijn van de auto-entiteit.
Hoe u dit in uw taal implementeert, is van ondergeschikt belang, aangezien op dat niveau zaken als leesbaarheid veel belangrijker zijn.