Attempting translation uml composition into code [uml]

Question

I am trying to understand the translation of uml composition into code. I have question about three example of code where Dog has Memory. Can these three examples be considered a composition (compositions in the meaning of uml)?

Example 1

class Memory {
    // CODE
}

class Dog {
    private Memory variable;

    Dog(Memory variable) {
        this.variable = variable;
    }
}

class Factory {
    Dog createDog() {
        Memory memory = new Memory() // memory contains reference to object Memory only moment and after create dog don't use it
        return new Dog(memory);
    }
}

Example 2

class Memory {
    // CODE
}

class Dog {
    private Memory variable;

    Dog(Memory variable) {
        this.variable = variable;
    }
}

class Factory {
    Dog createDog() {
        return new Dog(new Memory());
    }
}

Example 3

class Memory {
    // CODE
}

class MemoryFactory {
    Memory createMemory() {
        return new Memory();
    }
}

class Dog {
    private Memory variable;

    Dog(MemoryFactory memoryFactory) {
        this.variable = memoryFactory.createMemory();
    }
}

class Factory {
    Dog createDog() {
        MemoryFactory factory = new MemoryFactory()
        return new Dog(factory);
    }
}

A little different example:

class Memory {
    // CODE
}

class Dog {
    private Memory variable;

    Dog() {
        this.variable = new Memory();
        Other other = new Other();
        other.method(variable);
    }
}

class Other {
    void method(Memory memory) {
        // code which don't save reference to memory
    }
}

This is further composition?

There's basically no difference with your last example except that you have one more association. Please try to understand the answers first. — qwerty_so, Jul 10 '17 at 10:37

Peter Uhnak · Answer 1 · 2017-07-10T10:26:16.683

Yes; all the examples are identical in respect to composition:

class Dog {
    private Memory variable;
}

which is equivalent to

The way you create Dog/Memory is irrelevant here to the connection between the class, which always end up being the same. (Composition is about structure; the way you create it is about behavior.)

Regarding example storing temporarily the Memory instance:

This will most likely be optimized by the compiler to the example without temporary variable, but the more interesting question would be what if you kept the reference; in which case the Dog-Memory relation would no longer be (UML) composite aggregation, but at best either association or a shared aggregation (see also What is the difference between association, aggregation and composition? )

Regarding the last example: that's fine, as long as you uphold the lifecycle management as explained by Thomas.

Seems you added the missing point meanwhile :-) I'll leave my answer (or addendum) anyway, but this get's an up-vote. — qwerty_so, Jul 10 '17 at 09:17
I saw your answer as I was typing it, but you are still explaining it in a greater detail. — Peter Uhnak, Jul 10 '17 at 09:31

qwerty_so · Answer 2 · 2017-07-17T23:16:23.857

Basically I concur with Peter's answer. However, composition (or to be formally correct composite aggregation in contrast to shared aggregation which has almost no semantics) is about lifetime of objects. So you do have a simple association and showing that is usually enough. Depending on how the runtime implementation of your desired language is done, the Memory object will or will not die away when the Dog object dies. This fact can not be seen from the implementation (directly). E.g. in some languages there's object references counting an if you use a Memory object somewhere else during runtime it will live on though the Dog is already dead.

Showing a composite aggregation in a UML diagram tells the coder to take care that once the master object dies there is no reference left to the composite and memory management will take it to the bit grave too. In terms of a database implementation it's a foreign key constraint that needs to be set. A RDBMS will delete the aggregates when their master is deleted (if the programmer/DBA has set the right constraint for a composite aggregation: ON DELETE CASCADE).

Your statement that "A RDBMS will delete the aggregates when their master is deleted" is only true if the DB developer has defined the rule ON DELETE CASCADE, corresponding to the case of non-separable components (see https://stackoverflow.com/a/35214676/2795909) — Gerd Wagner, Jul 17 '17 at 14:44
@GerdWagner You are probably right (I'm no DBA). The emphasis is on the 2 sentences before (which implies you need to the the ON DELETE CASCADE). — qwerty_so, Jul 17 '17 at 23:14

Attempting translation uml composition into code [uml]

2 Answers2