This repertoire of notes on OOP was never before intended to stand also alone. It also represents a check out of OO circa early on to mid 1990s. Some civilization still uncover them useful, so here they are, caveat emptor. Special thanks to Gilbert Benabou for taking to time to compile the initially printable variation of this record and inspiring us to carry out it.
You are watching: When you make a copy of the aggregate object and of the objects it references,
< PDF > Printable VersionTable of Contents
Different authors use various terms for the idea of containment. UML has actually a really particular use (and various symbols) of the terms aggregation and complace, though this is not necessarily continual with OO authors. For the document, UML aggregation is "weak containment", typically implemented with pointers, and also the symbol is an open up diamond. Complace is "solid containment", enforced by worth, and also the symbol is a filled diamond.
An accumulation object is one which contains various other objects. For example, an Airaircraft class would contain Engine, Wing, Tail, Crew objects. Sometimes the class aggregation coincides to physical containment in the model (prefer the airplane). But periodically it is even more abstract (e.g. Club and also Members).
Whereas the test for inheritance is "isa", the test for aggregation is to watch if tright here is a whole/part connection in between two classes ("hasa"). A synonym for this is "part-of".
Being an aggregated object of some class indicates that objects of the containing class can message you to execute work-related. Aggregation gives a simple way for two objects to recognize about each various other (and for this reason message each other). Can the consisted of object message the container object? Is the connection symmetrical?
Should the aggregation be done by worth or by reference?
By worth means that the lifetimes of the objects are exactly the same; they are born and also die at the very same time; they are inseparable in the time of their lifetimes. Aggregation by worth cannot be cyclic: one object is the totality, one the component.
By reference de-couples the lifetimes of the 2 objects. The entirety might not have a part, or it might have a different component at different times. Different wholes might share the exact same component. De-allocating the entirety won"t automatically de-allocate the component. Aggregation by referral enables for the part to be aware of its entirety.Example
A List class might look favor this. This list stores integers.
class List public: List(); void addToFront(int); int firstElement(); int length(); int includes(int); void remove(int);private: // some data framework for // storing integer elements;The List course might be quite handy for producing a new Set course, given that the behavior is comparable. One method to execute this is to use a List object to manage the information of the Set, via aggregation.
class Set public: Set(); void add(int); int size(); int includes(int);private: List data;;Now we deserve to pretty quickly implement Set in regards to the use accessible in List:
int Set::size() rerevolve data.length();int Set::includes(int newValue) rerevolve data.includes(newValue);void Set::add(int newValue) if( ! includes(newValue) ) information.addToFront(newValue); // else, no-op, considering that sets can only have // one copy of any type of provided valueThis mirrors composition/aggregation by value, since the List element ivar of Set is statically claimed. Eextremely Set object always has actually a List object. Delete a Set, the List goes ameans as well, with no distinct action forced.
See more: If The Shoe Fits Wear It Quotes, Why Do We Say If The Shoe Fits, Wear It
Note that you must problem about the List ivar object being properly initialized, so the constructor to Set should perform this:
Set::Set() : data() // other stuff for Set, as neededThe area on Inheritance will certainly consider a design different for our implementation of Set.UML representation
UML distinguishes between complace and aggregation. (These are regularly associated terms.)