java - Association or Aggregation relationship for Facade design pattern?

Question

I'm studying the GoF design patterns, in particular the Facade pattern. I understand its use and implementation, but I have a doubt about its UML model. The solution proposed by my professor, summarized, is the following:

public class Facade{
    private ClassA c1;
    private ClassB c2;
    private ClassC c3;

    public Facade(){
        this.c1 = new ClassA;
        this.c2 = new ClassB;
        this.c3 = new ClassC;
    }

    public void FacadeMethod(){
        ...
        c1.operationA();
        c2.operationB();
        c3.operationC();
        ...
    }

}

The UML model proposed is like this:

The Facade Class has an association relationship with the classes ClassA, ClassB, ClassC. However should these be aggregation relationships? The Facade Class has reference c1 to ClassA, c2 to ClassB and c3 to ClassC, so i think it's a "HAS-A" relationship. Any Idea?

Answer 1

Preliminary remark

Many sources tend to use UML-aggregation for graphically representing object-composition. A popular source encouraging this trend is for example wikipedia. This is however not to be recommended.

Your professor is (almost) correct for notation and facade example

Your professor uses object-composition in the code of the facade implementation, and represents this with a navigable association which is correct. Some experts claim that this would be much better to use the dot notation of the association end ownership

Your professor uses object-composition and forward facade calls to objects. This is a valid implementation of a facade:

• GoF explicitly states page 187 that "[the facade] delegate client requests to appropriate subsystem objets" which clearly allow object-composition.

• While this is not the most commonly used way to implement a facade (often class-methods are used instead), GoF further describes implementation alternatives page 188:

  An alternative to subclassing [ of an abstract facade class ] is to configure a facade object with different subsystem objects. To customize the facade, simply replace one or more of its subsystem objects.

---

Additional arguments

Can you use UML-aggregation for representing object-composition?

In apparence, using UML-aggregation for modelling object-composition does not seem fundamentally wrong: UML does not define aggregation semantic very well and leaves room for interpretation. On page 110 of UML specs it's explained that:

• an aggregation is when one instance is used to "group together a set of instances" - but nothing forbids the set to be limited to one member.
• "Precise semantics of shared aggregation (aka white diamond) varies by application area and modeler" - so why not (mis)use it for object composition

While this is a valid interpretation, it comes with some flaws:

• Many modellers migh misunderstand the aggregation to have a * multiplicity by default, in view of the wording "a set of instances", and sets are not by default singletons. When UML-aggregation is used for object composition the multiplicity of 1 should be made explicit to avoid misunderstandings.

• A more carefull reading of page 110 shows that aggregation is in reality meant to model a part-whole relationship. Using it for object-composition in other cases is therefore a misuse of the UML aggregation (not wrong, but not the intent):

  a Property has an aggregation property (...); the instance representing the whole group is classified by the owner of the Property, and the instances representing the grouped individuals are classified by the type of the Property.

• This interpretation of groups of objects is reinforced page 198, being understood that the main difference between UML composite aggregation and shared aggregation is the ownership of the aggregated items:

  A binary Association may represent a composite aggregation (i.e., a whole/part relationship).

• Booch, Rumbaugh and Jacobson, the founders of UML, confirm this in their non-normative but much more readable book "The UML User's guide":

  (...) aggregation, which represents a “has-a” relationship, meaning that an object of the whole has objects of the part. Aggregation is really just a special kind of association and is specified by adorning a plain association with an unfilled diamond at the whole end.

Taking into account this weak semantic, we can summarize: UML-aggregation may be implemented using object-composition. But not all object-composition implement UML-aggregates. It's not a one-to-one mapping between both concepts.

Should you use aggregation at all?

We can conclude with Martin Fowler's quote out of his excellent book "UML Distilled" in which he analyses the difficulty to explain the difference between aggregation and a normal association, independently of any implementation considerations:

Aggregation is strictly meaningless; as a result I recommend that you ignore it in your own diagrams. If you see it in other people's diagrams, you'll need to dig deeper to find out what they mean by it. Different authors use it for different purpose.