000. UML Object Lifetime: Aggregation, Composition, Association - sukhoi1/Patterns-UML GitHub Wiki

Practical UML Approach / VS2015 .classdiagram (is available in VS Enterprise)

The command pattern is a design pattern that enables all of the information for a request to be contained within a single object. The command can then be invoked as required, often as part of a batch of queued commands with rollback capabilities.

Questions:

  • Client relations are not clear (why not ---> three times)?

In our diagrams, a plain arrowhead line denotes acquaintance. An arrowhead line with a diamond at its base denotes aggregation.

https://www.codeproject.com/Articles/455228/Design-Patterns-of-Behavioral-Design-Patterns


Elements of reusable Object-oriented Software:

  • In our diagrams, a plain arrowhead line denotes acquaintance;
  • An arrowhead line with a diamond at its base denotes aggregation;
  • Inheritance: white-box reuse;
  • Composition: black-box reuse;
  • In delegation, two objects are involved in handling a request: a receiving object delegates operations to its delegate (delegation is a way of making composition as powerful for reuse as inheritance);

Ultimately, acquaintance and aggregation are determined more by intent than by explicit language mechanisms. The distinction may be hard to see in the compile-time structure, but it's significant. Aggregation relationships tend to be fewer and more permanent than acquaintance. Acquaintances, in contrast, are made and remade more frequently, sometimes existing only for the duration of an operation. Acquaintances are more dynamic as well, making them more difficult to discern in the source code.


http://www.dofactory.com/net/command-design-pattern

Referenses:

  • Martin Fowler, UML Distilled: class diagrams Chapter 3 (class diagram the essentials) and Chapter 5;
    • attributes and
    • associations;

In the pre-UML days, people were usually rather vague an what was aggregation and what was association. Whether vague or not, they were always inconsistent with everyone else.

Aggregation is strictly meaningless; as a result, I recommend that you ignore lt in your own diagrams. If you see lt in other people's diagrams, you'11 need to dig deeper to find out what they mean by it. Different authors and teams use lt for very different purposes.

  • Instantiator ------|> Instantiatee;
  • ParentClass <| Subclass;
  • Agregation: Agregator <>______> Agregatee;
  • Composition: <#>______> ;

  • A dashed arrowhead line indicates a class that instantiates objects of another class;

Object Lifetime

...

UML: Association, Composition, Aggregation

https://stackoverflow.com/a/10394722

Temporary association A usage inside a method, its signature or as a return value. It's not really a reference to a specific object.

Association (also referred to as delegation) I have a relationship with an object. Foo uses Bar.

 public class Foo { 
     void Baz(Bar bar) {
     } 
 };

Aggregation I have an object which I've borrowed from someone else. When Foo dies, Bar may live on.

Let's take an example of Department and teacher. A single teacher can not belong to multiple departments, but if we delete the department, the teacher object will not be destroyed. We can think about it as a “has-a” relationship.

 public class Foo { 
     private Bar bar; 
     Foo(Bar bar) { 
        this.bar = bar; 
     }
 }

Composition is again specialised form of Aggregation and we can call this as a “death” relationship. It is a strong type of Aggregation. Child object does not have its lifecycle and if parent object is deleted, all child objects will also be deleted.

Let's take again an example of relationship between House and Rooms. House can contain multiple rooms - there is no independent life of room and any room can not belong to two different houses. If we delete the house - room will automatically be deleted.

 public class Foo {
      private Bar bar = new Bar();
 }

Too wordy, skip this: Inheritance vs. composition, Listkov Substitution

⚠️ **GitHub.com Fallback** ⚠️