implementazione di composizione e aggregazione in C#?

Question

Come faccio a/(qual è il modo migliore per) implementare composizione e aggregazione in C#?

Grazie 123Developer

Answer 1

Questa è una domanda abbastanza astratto, visto che sia l'aggregazione composizione & sono abbastanza simili & davvero solo diverso concettualmente e non necessariamente a livello di codice. (Ad esempio, potresti considerare una macchina con un motore come composizione e un cane con le pulci come aggregazione, ma non c'è nulla che ti impedisca di implementarle nello stesso modo se le stessi modellando nel codice).

Tuttavia, se si vuole abbattere le differenze & provare & forzatamente aggiungere decisioni di progettazione software per evidenziare queste differenze Credo che si potrebbe fare qualcosa di simile ... prendere an example from Wikipedia:

aggregazione differisce dalla ordinaria composizione in quanto non implica la proprietà. In composizione, quando l'oggetto proprietario viene distrutto, lo sono anche gli oggetti contenuti. In aggregazione, questo non è necessariamente vero. Ad esempio, un'università possiede vari dipartimenti (ad esempio, chimica) e ogni dipartimento ha un numero di professori. Se l'università si chiude, i dipartimenti non esisteranno più, ma i professori di tali dipartimenti continueranno ad esistere. Pertanto, un'università può essere vista come una composizione di dipartimenti, mentre i dipartimenti hanno una aggregazione di professori. Inoltre, un professore potrebbe lavorare in più di un dipartimento, ma un dipartimento non potrebbe far parte di più di un'università.

Si potrebbe costruire questo codice per rappresentarla (con il maggior numero di indicazioni artificiosa di composizione/aggregazione):

public class University : IDisposable 
{ 
    private IList<Department> departments = new List<Department>(); 

    public void AddDepartment(string name) 
    { 
     //Since the university is in charge of the lifecycle of the 
     //departments, it creates them (composition) 
     departments.Add(new Department(this, name)); 
    } 

    public void Dispose() 
    { 
     //destroy the university... 
     //destroy the departments too... (composition) 
     foreach (var department in departments) 
     { 
      department.Dispose(); 
     } 
    } 
} 

public class Department : IDisposable 
{ 
    //Department makes no sense if it isn't connected to exactly one 
    //University (composition) 
    private University uni; 
    private string name; 

    //list of Professors can be added to, meaning that one professor could 
    //be a member of many departments (aggregation) 
    public IList<Professor> Professors { get; set; } 

    // internal constructor since a Department makes no sense on its own, 
    //we should try to limit how it can be created (composition) 
    internal Department(University uni, string name) 
    { 
     this.uni = uni; 
     this.name = name; 
    } 

    public void Dispose() 
    { 
     //destroy the department, but let the Professors worry about 
     //themselves (aggregation) 
    } 
} 

public class Professor 
{ 
} 

Answer 2

Beh, in un mondo in garbage collection in cui tutti gli oggetti sono accessibili tramite i riferimenti, la sottile differenza (di proprietà) tra rigorosa composizione e sfuma un po 'di aggregazione - in modo in generale (quando si utilizza classi) si riduce a un campo per l'altro oggetto o la raccolta:

class Building { 
    private readonly List<Room> rooms = new List<Room>(); 
    public IList<Room> Rooms {get {return rooms;}} 

    public Address Address {get;set;} 
    //... 
} 
class Address { 
    public string Line1 {get;set;} 
    public string PostCode {get;set;} 
    //... 
} 
class Room { 
    public string Name {get;set;} 
    public int Capacity {get;set;} 
    //... 
} 

Se ho mancato il punto, chiarire ...

Le cose sono più coinvolti quando si discutono struct s - ma in genere quando si parla di concetti OO, struct utilizzo è limitato ai campi valore ...