implementation of composition and aggregation in C#?

Question

How do I/(what is the best way to) implement composition and aggregation in C#?

Thanks 123Developer

Solution 1

That's a pretty abstract question, given that both composition & aggregation are pretty similar & really only different conceptually and not necessarily at the code level. (i.e. you might consider a Car having an Engine to be composition, and a Dog having fleas to be aggregation, but there's nothing stopping you implementing them in the same way if you were modelling them in code).

However, if you want to break down the differences & try & forcibly add software design decisions to highlight those differences I guess you could do something like this... taking an example from Wikipedia:

Aggregation differs from ordinary composition in that it does not imply ownership. In composition, when the owning object is destroyed, so are the contained objects. In aggregation, this is not necessarily true. For example, a university owns various departments (e.g., chemistry), and each department has a number of professors. If the university closes, the departments will no longer exist, but the professors in those departments will continue to exist. Therefore, a University can be seen as a composition of departments, whereas departments have an aggregation of professors. In addition, a Professor could work in more than one department, but a department could not be part of more than one university.

You might build this code to represent it (with as many contrived indications of composition/aggregation):

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
{
}

Solution 2

Well, in a garbage collected world where all objects are accessed via references, the subtle difference (in ownership) between strict composition and aggregation blurs a little - so in general (when using classes) it boils down to a field for the other object or collection:

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

If I've missed the point, please clarify...

Things are more involved when you discuss structs - but generally when talking about OO concepts, struct usage is limited to value fields...

Comments

[Francisco Soto]

Old question but i stumbled upon it, I would just recommend that if Department is to be only composited, you can enforce that by having it being a nested class inside university and making it private. Thus making imposible for any other place to even declare a Department and leaving the parent/child relationship explicit.