Are Setters described as Aggregation/Composition?

[Peter Kovac]

Hi,

I have a code like this, where Foo is passed to Bar (e.g. by Spring wiring):

class Bar {
    private  Foo foo;

    void setFoo (Foo _f)
    {
        foo = _f;
    }

    void exec() {
         foo.XXXXX
    }
}

Will UML look like this or is it a simple dependency?

-------          -------
| Bar |<>--------| Foo |
-------          -------

Thanks,

[Matthew Brown]

In my opinion, you can't tell from an example like that. It depends on the meanings of Foo and Bar, and more importantly on the meaning of the relationship between them. Can you consider the Foo to be part of the Bar? If so then it's probably an aggregation or a composition. So you really need a more concrete example to say anything definite.

[Junilu Lacar]

The setter has nothing to do with composition or aggregation. The two terms are about a relationship between two or more objects. Whereas composition implies ownership, aggregation doesn't. That is, with composition, if the "owning" object goes away, so does the "owned" object. With aggregation, the aggregated object can still continue to exist even without the aggregating object. See http://en.wikipedia.org/wiki/Object_composition#Aggregation

[Junilu Lacar]

I suppose that one could argue that using a setter to establish a relationship implies one or the other but I can give examples that show this is not true. If you say that invoking a setter implies aggregation, a setter implementation could clone/copy the object passed in and "own" the clone, thus, it's composition. The reverse argument could be made in favor of aggregation. I suspect that in most cases where an object reference is passed to a setter, it does indeed establish an aggregation relationship but you should not assume that is always the case.

[Wirianto Djunaidi]

It is not as simple of translating from code to UML. UML is supposed to express your design & intention, so from conceptual point of view aggregation & composition hold different meaning..but when it is translated to code they might end up being implemented the same way. This is similar with design patterns, a lot of design patterns have similar implementation code-wise but the design pattern itself convey the meaning or intent that the designer want to solve.

Having said that, from my previous experience working on code generation portion of UML tools, typically the translation from UML to Code are:
- Aggregation/Composition implemented as an array or collection
- regular link implemented as standard single attribute of the object

Setter/getter has no direct meaning toward the relationship whether it is simple relationship or aggregation/composition, from UML design point of view it is irrelevant. Most UML tools can be customized to generate getter/setter, parameterized constructor, or both for all the important attributes.