Associations between the classes with aggregation

Question

I need to create an UML Class Diagram and I am not sure if I've done it correctly.

I will show you on example. So ClassA has an instance of ClassB and ClassA calls methods from ClassC which take as attributes variables from ClassA and ClassB. Should I connect also ClassC with ClassB? Does the association between ClassA and ClassB should be directed? The implementation of the code below:

ClassB {
    constructor() {
        this.str1 = "Hello";
    }
}

ClassA {
    constructor() {
        this.str2 = "World";
        this.objB = new ClassB();
    }
    funA() {
        let objC = new ClassC();
        objC.function1(this.objB.str1);
        objC.function2(this.str2);
    }
}

ClassC {
    constructor() {}
    function1(stringFromB) {
        console.log(stringFromB);
    }
    function2(stringFromA) {
        console.log(stringFromA);
    }
}

let objA = new ClassA();
objA.funA();

Thanks for any help :)

score -1 · Accepted Answer · answered Jan 06 '19 at 02:29

-1

Composite aggregation is about life-time of objects. There's noting in your code that shows a need for that.

(N.B. I don't know the Java scoping rules so I took this.objB as being private.) There's one association which is an owned property of ClassA (shown by the dot) named objB. The dependency to ClassC comes from the (temporarily used) objC which is not on class level. It could be discussed whether an association would match (honestly I'd had to dig deeper into the specs), but a dependency isn't wrong in any case (because it's weaker than an association and definitely A depends on B).

Another N.B. re. your CD: The functions in the code take strings, not objects and one of them misses the trailing 1.

answered Jan 06 '19 at 02:29

qwerty_so

35,448
8
62
86

Composite aggregation (in the sense of UML) is **NOT** about life-time of objects (this is a widespread misunderstanding resulting from a terminological tradition in the C++ community). Rather, composite aggregation is about the question if parts/components are shareable or not. – Gerd Wagner Jan 06 '19 at 18:11
@GerdWagner Read the box on p. 110 – qwerty_so Jan 06 '19 at 22:50
On the same page they say: "NOTE. A part object may (where otherwise allowed) be removed from a composite object before the composite object is deleted, and thus not be deleted as part of the composite object." While the spec is contradictory on the issue of a lifecycle dependency, it is clear on the issue of non-shareabilty of parts. Therefore, lifecycle dependency is **NOT** a defining characteristic, as I have argued in https://stackoverflow.com/questions/734891/aggregation-versus-composition/27889087#27889087 – Gerd Wagner Jan 07 '19 at 12:23
@GerdWagner I'd rather go with the top answer there. Aggregation is just not worth to use it in almost all contexts. So (except you have a definite use) you just should not use it. – qwerty_so Jan 07 '19 at 13:31
My point is not about using aggregation, but about avoiding to repeat the misconception that "composite aggregation is about life-time of objects", as you have put it. – Gerd Wagner Jan 07 '19 at 13:53
@GerdWagner I just think we will not agree. Even a compromise can only be found with a lengthy discussion which will not fit here. – qwerty_so Jan 07 '19 at 14:36
But this effectively means that you don't want to delete or change your wrong statement ("composite aggregation is about life-time of objects") and you don't want to further justify this (and prefer not to read/understand the arguments provided in the SO answer referenced above). – Gerd Wagner Jan 07 '19 at 14:43
Well, how about you? Got fed wisdom with a spoon? Just that you think you are right does not mean you are right. – qwerty_so Jan 07 '19 at 17:23

Associations between the classes with aggregation

1 Answers1

Linked