implementacja kompozycji i agregacja w języku C#?

Question

Jak i/(jaki jest najlepszy sposób) zaimplementować kompozycję i agregację w języku C#?

Dzięki 123Developer

Answer 1

To dość abstrakcyjne pytanie, biorąc pod uwagę, że zarówno agregacja kompozycja & są dość podobne & naprawdę tylko różne koncepcyjnie i niekoniecznie na poziomie kodu. (np. możesz rozważyć samochód z silnikiem, który ma być kompozycją, a pies ma pchełki do agregacji, ale nic nie stoi na przeszkodzie, abyś zastosował je w ten sam sposób, jeśli modelujesz je w kodzie).

Jednakże, jeśli chcesz przełamać różnice & spróbować & przymusowo dodać decyzji projektowych oprogramowanie do podkreślenia tych różnic Myślę, że można zrobić coś takiego ... biorąc an example from Wikipedia:

Agregacja różni się od zwykłych w tym sensie, że nie oznacza to własności. W kompozycji, gdy obiekt będący właścicielem jest niszczony, podobnie są zawarte obiekty. W agregacji nie musi to być prawda. Na przykład uniwersytet jest właścicielem różnych działów (np. Chemii), a każdy wydział ma wielu profesorów. Jeśli uniwersytet zostanie zamknięty, wydziały przestaną istnieć, ale profesorowie tych wydziałów nadal będą istnieć. Dlatego uniwersytet może być postrzegany jako kompozycja działów, podczas gdy wydziały mają skupiska profesorów. Ponadto profesor mógł pracować w więcej niż jednym dziale, ale wydział nie mógł być częścią więcej niż jednego uniwersytetu.

Można zbudować ten kod do reprezentowania go (z tak wieloma contrived oznaczeń składu/agregacji):

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

Cóż, w pewnym śmieci zbierane świecie, gdzie wszystkie obiekty są dostępne poprzez referencje, subtelnej różnicy (w eksploatacji) między ścisłego składu i agregacji zaciera trochę - tak w ogólnym (przy użyciu klas) sprowadza się do pola dla innego obiektu lub kolekcji:

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;} 
    //... 
} 

Jeśli Tęskniłam punkt, proszę wyjaśnić ...

Rzeczy są bardziej zaangażowani, kiedy dyskutować struct s - ale ogólnie mówiąc o koncepcji OO, struct wykorzystanie jest ograniczone do wartości pól ...