C# Code for Association, Aggregation, Composition

C# code for association, aggregation, composition

The difference between aggregation and composition is pretty fuzzy and AFAIK relates to the logical existence of the "child" objects after the container is destroyed. Hence, in the case of aggregation the objects inside the container can still exist after the container object is destroyed, while in the case of composition design demands that they also get destroyed. Some analogies:

• A Car object containing four Wheel objects. Normally if you destroy the car (by calling some method to clean it up) you should also destroy the wheels in the process, since it makes little sense for them to exist outside the car (unless you move them to another Car object). More realistically, a reader object wrapping an input stream will also close the inner stream when it gets closed itself. This is composition.
• A Person object contains (owns) a Radio object. If the Person dies, the Radio may be inherited by another Person i.e. it makes sense for it to exist without the original owner. More realistically, a list holding objects does not demand that all objects get disposed when the list itself is disposed. This is aggregation.

Edit: After reading your links I'd be inclined to go with the first one, since it gives an explanation similar to mine.

Also association is merely invoking a method (sending a message) to another object via a reference to that object.

Understanding the Aggregation, Association, Composition

In concise

Association - There are two objects that know about each other, but they can't affect to each other's lifetime.

Composition - There are two classes: A and B.Object of the class A contains a class B object, and can't logically be created without class B.

Aggregation - is a variant of the "has a" association relationship; aggregation is more specific than association. It is an association that represents a part-whole or part-of relationship.

In your examples, 1, and 3 are Compositions, because they contain class B object.Example 4 is Association, because it only knows about class B and only uses it's object as a local variable.Example 2 is and Aggregation.

For more you can read in wiki
https://en.wikipedia.org/wiki/Class_diagram

EDITED:

Difference between Composition and Aggregation.

Composition relationship: When attempting to represent real-world whole-part relationships, e.g. an engine is a part of a car.

Aggregation relationship: When representing a software or database relationship, e.g. car model engine ENG01 is part of a car model CM01, as the engine, ENG01, may be also part of a different car model.

In your example 1, your create an object of class B in your class A.Based on your code you can't give the created object of class B to another object of class A.
But in your example 2, you are giving object B as an parameter.So you can create many objects of class A and give them the same object B

association, aggregation and composition

Association is a relationship where all object have their own life cycle and there is no owner. Let’s take an example of Teacher and Student. Multiple students can associate with a single teacher and a single student can associate with multiple teachers but there is no ownership between the objects and both have their own lifecycle. Both can be created and deleted independently.

Aggregation is a specialized form of Association where all objects have their own lifecycle but there is an ownership: a child object can not belong to another parent object. Let’s take an example of Department and teacher. A single teacher can not belong to multiple departments, but if we delete the department the teacher object will not be destroyed. We can think about it as a “has-a” relationship.

Composition is again a specialized form of Aggregation and we can call this as a “death” relationship. It is a strong type of Aggregation. Child objects does not have their life cycle and if the parent object is deleted all child objects will also be deleted. Let’s take again an example of relationship between House and rooms. A house can contain multiple rooms and there is no independent life for a room and a room can not belong to two different houses. If we delete the house its rooms will be automatically deleted. Let’s take another example relationship between Questions and options. Single questions can have multiple options and an option can not belong to multiple questions. If we delete a question its options will also be deleted.

composition and aggregation example with UML class diagram

Yes, What you do is call composition, if you want to do aggregation you to it like this:

Class Client
{

    BankAccount acc;

    public Client(BankAccount p_acc)
    {
      acc=p_acc;
    }

    public void addMoneyToBankAccount(decimal amount)
    {         
        acc.AddMoney(amount);
    }

    public decimal CheckBalance()
    {
        return acc.CheckAccountBalance();
    }

}

Aggregation:

If inheritance gives us 'is-a' and composition gives us 'part-of', we could argue that aggregation gives us a 'has-a' relationship. Within aggregation, the lifetime of the part is not managed by the whole. To make this clearer, we need an example. For the past 12+ months I have been involved with the implementation of a CRM system, so I am going to use part of this as an example.

The CRM system has a database of customers and a separate database that holds all addresses within a geographic area. Aggregation would make sense in this situation, as a Customer 'has-a' Address. It wouldn't make sense to say that an Address is 'part-of' the Customer, because it isn't. Consider it this way, if the customer ceases to exist, does the address? I would argue that it does not cease to exist. Aggregation is shown on a UML diagram as an unfilled diamond.

As I said at the beginning of the answer, this is my take on composition and aggregation. Making the decision on whether to use composition or aggregation should not be a tricky. When object modelling, it should be a matter of saying is this 'part-of' or does it 'have-a'?

implementation of composition and aggregation in C#?

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

C# Composition - not fully sure I am implementing correctly

You've identified that your menu HAS categories, but have implemented it the other way around (in your code, your category HAS a menu). The references are going from the leaf nodes to the parent, instead of the parent containing a collection of references to the items it contains.

The other thing that I find unusual about what you have posted is that all the members are private. You can expose properties to the outside world, and at some point you are going to need a way to view and present the data contained within a Menu to the user.

I would rewrite the classes to look more like this:

public class Menu
{
    public Menu() { }

    public Menu(long id, string name)
    {
        Id = id;
        Name = name;
    }

    public long Id { get; }

    public string Name { get; set; }

    public List<Category> Categories { get; } = new List<Category>();
}

Note that I've used a get for some, and a get/set for others. This is just an assumption, but you don't normally want the id of objects to change. Likewise, initializing the list and keeping it get-only means that users don't have to do a null check every time they work with it.

---

Related Topics