how are association, aggregation and composition written?

Question

i have read some posts about the differences between these 3 relationships and i think i get the point.

i just wonder, are all these written the same when coding?

question 1: all 3 are just a value of the object type in a instance variable?

class A {
    public $b = ''

    public function __construct($object) {
         $this->b = $object // <-- could be a association, aggregation or a composition relation?
    }
}

question 2: does it have to be an instance variable or can it be a static one?

class A {
    public static $b = '' // <-- nothing changed?

    public function __construct($object) {
         $this->b = $object
    }
}

question 3: is there a difference in where the object is created?

i tend to think that composition object is created inside the object:

class A {
    public $b = ''

    public function __construct() {
         $this->b = new Object // is created inside the object
    }
}

and aggregation/association is passed through a constructor or another method:

class A {
    public $b = ''

    public function __construct($object) { // passed through a method
         $this->b = $object
    }
}

question 4: why/when is this important to know. do i have to comment an object inside another what relation its about or do you do it in an UML diagram?

could someone shed a light on these questions.

thanks!

Answer 1

Wikipedia: Class Diagrams probably has your best definitions. None of your examples distinguish between association, aggregation, or composition. Without any definition of what A is, or what B is, there is no definition of what their relationship is. How the reference to the other object is obtained is irrelevant to class diagrams.

Answer 2

Hey @ajsie

You are right that these are typically realized as object references, which of course are usually just member fields of some class. This is only because it's natural in an object-oriented system, this can map to other things in different contexts, e.g. foreign keys in a relational database.

As mentioned by @erisco the specifics of the relationship can only be taken in context of the overall model. For example, we can read a composition relationship between a Purchase Order and an Order Line like this (for example): a Purchase Order comprises one or more Order Lines.

I usually interpret the three you give as follows:

1. Association: A knows of B, B has meaning in its own right.
2. Aggregation: A includes B, B is externally identifiable and may exist on its own merits.
3. Composition: A comprises B, B is not externally identifiable or does not have meaning outside of this composition.

That said, I have seen these used to mean pretty much anything that can be dreamed up (and there are very likely people on SO who will disagree with my assessment!) so take care when interpreting someone else's diagrams :-) The above conventions have served me well but YMMV.

Re question 2: A static reference would yield a common association across instances, but it is just one way to implement that, and might be surprising to consumers.