2

As far as my understanding for composition, the children cannot exist without the parent. But my instructor is suggesting that the following example is an aggregation, I just want another opinion.

class ItemForKids { }
class ItemForMen { }
class ItemForWomen { }
class PageContent {
    private:
        ItemForKids* itemForKids = NULL;
        ItemForMen* itemForMen = NULL;
        ItemForWomen* itemForWomen = NULL;
    public:
        PageContent() {
            this->itemForKids = new ItemForKids();
            this->itemForMen = new ItemForMen();
            this->itemForWomen = new ItemForWomen();
        }
        ~PageContent() {
            delete this->itemForKids;
            delete this->itemForMen;
            delete this->itemForWomen;
        }
}

2 Questions:

  1. Is above example aggregation or is it composition?
  2. My instructor suggests that if we change the pointers to regular variable then we don't need to initialize the object in constructor and then it will become composition, is this true?
  • 1
    This is in fact a duplicate of softwareengineering.stackexchange.com/questions/182271/… but you would not find it because this question actually uses the better counter-term containment. These days the term composition is most often used as meaning "not inheritance". – Martin Maat Jun 30 '18 at 11:04
  • If your teacher prefers to use composition for non-pointer members and aggregation for pointer members (which is C++ specific issue, opposed to the former comment), then let him/her do, this is not inherently wrong. But wait, I found a real dupe, the question mentioned by @MartinMaat is only valid for C#, not for C++. – Doc Brown Jun 30 '18 at 11:45
  • 2
    Possible duplicate of C++ : Association, Aggregation and Composition – Doc Brown Jun 30 '18 at 11:45
1

The aggregation vs. composition distinction is not terribly relevant in practice. In C++, it is better to talk about ownership: who owns a particular object and is responsible for destroying it?

The majority of C++ objects are used by value and are therefore destroyed automatically. This code is equivalent to the code you posted in the question:

class ItemForKids { };
class ItemForMen { };
class ItemForWomen { };
class PageContent {
    private:
        ItemForKids itemForKids;
        ItemForMen itemForMen;
        ItemForWomen itemForWomen;
    public:
        // PageContent() default constructor
        // ~PageContent() default destructor
};

Modern C++ code tries to do as much as possible by value because automatic destruction makes life so much easier (and eradicates a common source of errors). If using a value is not possible directly, we use smart pointers like std::unique_ptr that destroy the pointed-to object when they are destroyed.

In your question the PageContent class is responsible for deleting its itemForX members, so this can be characterized as “aggregation”. Your instructor is therefore mostly correct in this case. This is a simple case because the class both constructs and deletes its members. If ownership of the members is transferred into the class, e.g.

ProductPage(ItemForKids* itemForKids) {
  this->itemForKids = itemForKids;
}

then this is a more borderline case. I'd argue that this would still be best described as aggregation because there's still ownership (the responsibility to delete), but I do see that it could be argued differently.

So in the end, do what your instructor expects you to do, and forget about “aggregation” after the course. It is not useful for most programming, especially compared to concepts like ownership.

Note that aggregation has a related but distinct meaning in (relational) database systems.

  • In your question the PageContent class is responsible for deleting its itemForX members, so this can be characterized as “aggregation” here PageContent is being deleted along with it's children, don't you think it's opposite to aggregation? – sallushan Jun 30 '18 at 11:10
  • @sallushan With aggregation, the members do not outlive the containing object. The members are deleted together with the PageContent. If this was composition, then the members could live longer than the containing object. Someone else would own them. – amon Jun 30 '18 at 12:53
0

This is why I would rather not use the term composition in a software engineering context. Apparently it even confuses your teacher.

Whether the members are instantiated implicitly or explicitly does not matter. One speaks of aggregation when the class does not own them, indeed when their existence does not depend on the existence of the class that merely provides access to them. With aggregation the class is just a portal to the aggregated objects.

The example you provide is a case of containment.

  • I guess you are suggesting that the example is actually composition NOT aggregation? containment seems to be similar to composition. I agree that containment/ownership terminology is far better than composition or association. – sallushan Jun 30 '18 at 11:14

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.