A composition relationship is a type of association relationship. This means that one object will have another object as its property, but where it differs from aggregation is that, in composition, the object that is used as a property can't exist independently, it must have the help of another object in order to be functional. If we think about the Chef and Manufacturer classes, the existence of these classes is not fully dependent on the Food and Beverage classes. Instead, these classes can exist independently, and therefore have an aggregation relationship.

However, if we think about the relationship between the Order and OrderItem objects, we can see that the OrderItem object has no meaning without Order. Let's look at the following code of the Order class:

public class Order {
    public int OrderId { get; set; }
    public List<OrderItem> OrderItems { get; set; }
    public DateTime OrderTime { get; set; }
    public Customer Customer { get; set; }
}

Here, we can see that the Order object has a list of OrderItems in it. These OrderItems are the Food items that the customer has ordered. A customer can order one dish or multiple dishes, which is why the OrderItems is a list type. So now it's time to justify our thinking. Does an OrderItem really have a composition relationship with Order? Are we making any mistakes here? Are we thinking about an aggregation relationship as a composition relationship?

To identify which type of association relationship it is, we have to ask ourselves some questions. Can OrderItem exist without Order? If not, then why not? It's a separate object! However, if you think a little more deeply, you will realize that no OrderItem can exist without an Order, as a customer has to order an item, and without an Order object, the OrderItem object is not trackable. The OrderItem item cannot be served to any customer as there is no data for which customer the OrderItem is for. Consequently, we can say that the OrderItem has a composition relationship with the Order object.

Let's look at another example of composition. In our schooling system, we have students, teachers, subjects, and grades, right? Now, I would say that the relationship between a Subject object and a Grade object is a composition relationship. Let me justify my answer. Take a look at the following code of these two classes:

public class Subject {
    public int Id { get; set; }
    public string Name { get; set; }
    public Grade Grade { get; set; }
}

public class Grade {
    public int Id { get; set; }
    public double Mark { get; set; }
    public char GradeSymbol { get; set; } // A, B, C, D, F etc
}

Here, we can see that the Grade object holds the mark that a student has scored on a test for a particular subject. It also holds the GradeSymbol, such as A, B, or F, depending on the marking rules of that school. We can see in the Subject class that there is a property called Grade. This holds the grade for that particular Subject object. If we just think about Grade individually rather than in association with the Subject class, we will get a bit confused and wonder what subject the grade is for.

Consequently, the relationship between Grade and Subject is a composition relationship.

Let's look at how we can show a composition relationship in a UML diagram using the preceding example of Subject and Grade:

A solid line and a black diamond are used to represent a composition relationship. The diamond is placed at the side of the class that holds the property: