3

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: Facade UML Model

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?

sixpain
  • 342
  • 1
  • 5
  • 13

3 Answers3

4

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.

Christophe
  • 68,716
  • 7
  • 72
  • 138
  • About the multiplicity, it is common to consider it is 1 when it is missing (and I follow that (non)rule for the code generation in BoUML), but in the top of page 202 the norm says `NOTE. If no multiplicity is shown on the diagram, no conclusion may be drawn about the multiplicity in the model`. So to consider the multiplicity is "*" for an aggregation is as abusive as to consider it is 1 for the non aggregation – bruno Jul 04 '20 at 07:15
  • But `no multiplicity is shown on the diagram` can be understand in several ways, may be the multiplicity is not shown because of a drawing setting, or may be the multiplicity is not specified in the definition of the aggregation. It is quite perturbing the norm speak about diagram. UV for that new great answer. – bruno Jul 04 '20 at 07:32
  • 1
    @bruno yes, I fully agree: it’s as abusive to consider * or 1, since unspecified is unspecified. Interpretation should always made prudently and at own risks :-) The UML standard would have been inspired to give the aggregation explicitly the “has” semantic (Booch notation provided this semantic in his pre-UML notation, and OMT had it as well and even used the white diamond for it): this would have provided very elegantly for both aggregation and object composition. – Christophe Jul 04 '20 at 08:14
  • Thanks for the exhaustive answer. What confused me is the aggregation used in the Adapter pattern between Adapter Class and Adaptee Class. Both Wikipedia and my professor used a model like this: https://it.wikipedia.org/wiki/Adapter_pattern#/media/File:Adapter_using_delegation_UML_class_diagram.svg But basically the Adapter it only has a reference to an Adaptee object, so I don't think it's really a whole-part relationship – sixpain Jul 04 '20 at 09:40
  • The same approach is used in the Decorator, but I don't understand what is different from the situation in the Facade, in both cases is simply kept the reference to an object. https://it.wikipedia.org/wiki/Adapter_pattern#/media/File:Adapter_using_delegation_UML_class_diagram.svg – sixpain Jul 04 '20 at 09:46
  • 1
    @sixpain this is what I meant about the misuse of the UML aggregation notation for object-composition: Java objects have a reference semantic. Object-composition in java is the same as having an object reference. And while the white diamond can be defended, it is not a good practice in absence of part/whole relation. This practice is quite old: pre-UML OMT used white diamond for "has-a" and many used it for object composition. The part/whole appeared only later, when OMT and Booch were merged together with OOSE to make UML. – Christophe Jul 04 '20 at 10:54
  • 1
    @sixpain Interestingly, GoF (which uses OMT notation and not UML) do not use the diamond in the adapter. Their usage is however not consistent either. They use it with object-composition semantic for the bridge, the strategy and the decorator. They use it with aggregation semantic in the composite, the flyweight, the state, and the interpreter. They use it with unclear semantic in the command and the memento. ANd they don't use it in other patterns wher either composition or aggregation is used. I've edited to add a quote of Martin Fowler with advice about the usage of the UML aggregation – Christophe Jul 04 '20 at 11:15
3

However should these be aggregation relationships?

no, a Facade is not composed of ClassA ClassB and ClassC, e.g. these classes are not parts of Facade

bruno
  • 32,421
  • 7
  • 25
  • 37
  • Thanks! And what's the difference between this case and (for example) the Adapter Pattern? There the Adapter Class has an aggregation relationship with the Adaptee Class, due to the fact that Adapter has a reference to the Adaptee Object. Maybe i'm misunderstanding the aggregation meaning in java. https://imgur.com/a/uwz08xT – sixpain Jul 03 '20 at 09:27
  • @sixpain for me to use an aggregation for the adapter pattern is an error. A typical use of an aggregation is `Car <>--->Engine` because a Car is composed by (at least) an Engine. an adapter need and use an adaptee but is not composed by it – bruno Jul 03 '20 at 09:56
  • I agree with you, but on Wikipedia, on my book, and on my professor's model it's used the aggregation relationship. The only explanation I give myself about this, seeing the java implementation, is that Adapter has a reference to an Adaptee object so Adapter "HAS-A" Adaptee.https://it.wikipedia.org/wiki/Adapter_pattern#/media/File:Adapter_using_delegation_UML_class_diagram.svg – sixpain Jul 03 '20 at 12:55
  • @sixpain an implementation can indicate a composition (at least in C++, not sure in Java) but never an aggregate – bruno Jul 03 '20 at 13:09
1

Aggregation is a more specific form of association so the professor's solution is not wrong, but I think yours can be fine too

michsalv
  • 47
  • 5