The fallacy of association, composition, and aggregation in the Java Madness handout

This article is for example the following information (recommended reading):

a). Difference-aggregation-acquaintance-and-composition-as-used-by-gang-of-four

b). associationvsaggregationvscomposition

c). Design Patterns Elements of reusable object-oriented software

d). Java Madness Handout (third edition)

1. The origin of the problem

What I see is the third edition of this book, in 2.2.2 's conceptual understanding of UML class diagrams, the diagrams used in the book are as follows:

Watermark/2/text/ahr0cdovl2jsb2cuy3nkbi5uzxqv/font/5a6l5l2t/fontsize/400/fill/i0jbqkfcma==/dissolve/70/gravity /center ">

The text above the picture (the typography in the book) I don't think it's too much of a problem (in fact I think there's something wrong with it). Extracts such as the following:

Association relationships consist of two exceptions: aggregation and composition, all of which have partial and overall relationships, but generally feel that the combination is more stringent than aggregation.

When an entity is aggregated into one entity. The entity can also be part of an entity at the same time, for example. Students can be members of the basketball club. Can also be a member of a calligraphy club; When an entity is grouped into one entity. The entity cannot be part of an entity at the same time.

Aggregations are represented by a solid line with a hollow diamond frame, and the combination is represented by a solid line with a solid diamond frame.

The text on the bottom of the picture is Dog, extracts such as the following:

There is an aggregation relationship between student and Basketballclub. That is, 1 or more student entities are capable of synthesizing one basketballclub entity. There is a combined relationship between arm (arm) and student, and 2 arm entities are combined into one student entity.

2. Background knowledge

We introduce some background knowledge to warm up:

1. The first book on design Patterns-reusable object-oriented software based (design Patterns Elements of reusable object-oriented Software) was published in 1994
2. The Java language was launched in 1995
3. Uml1.x launched in 1997

There is a paragraph in design Patterns by Gang of four (alias for reference c) Section 1.6, which is called relating run-time and compile-time structures:

Consider the distinction between object aggregation and acquaintance and howdifferently they manifest themselves at Compil E-and Run-times. Aggregationimplies. One object owns or is responsible for another object. Generally wespeak of an object has or being part of another object. Aggregation Impliesthat an aggregate object and its owner has identical lifetimes. Acquaintance implies that an object merely knows of another object. Sometimesacquaintance is called "Association" or the "using" relationship. Acquaintedobjects may request operations of all other, but they aren ' t responsible foreach other. Acquaintance is a weaker relationship than aggregation and suggestsmuch looser coupling between objects .... Ultimately, acquaintance and aggregation is determined more by intent than byexplicit language mechanisms. The distinction may is hard-to-see with thecompile-time structure, but it's significant. Aggregation relationships tend tobe fewer and more permanent than acquaintance. AcquAintances, in contrast, Aremade and remade more frequently, sometimes existing only for the duration of anoperation. Acquaintances is more dynamic as well, making them more difficultto discern in the source code.

The main idea is the discussion of two words: Aggregation and acquaintance.

And the interesting thing is that the subsequent UML in the same definition of a aggregation concept, and then is association, composition.

Why do you say this is interesting? Since the two concepts of the same expression actually differ, the aggregation in UML actually says that the composition in Acquaintance,uml in the Gof (the alias of the reference Data C) is gof in aggregation. It's just that the concepts in UML are commonly used today.

3. Why is Falsehood

We can tell by the reference material except for D. What association says is actually the relationship between an object and its life cycle. Instead of the picture below ("That is, 1 or more student entities are capable of synthesizing a basketballclub entity, and there is a composite relationship between Aram (ARM) and student.") 2 arm entities are combined into one student entity ") the way in which the principal object is constructed by aggregating/combining objects. The difference between the two is very subtle. Chinese has not been 200 points very difficult to find (ah. Who threw the bricks).

Student and Basketballclub are aggregation relationships (accurately basketballclub aggregation student) and can be concluded that Basketballclub can have 0 or more student, and basketballclub to student life cycle no matter what responsibility, the same basketballclub death and student will not have a dime relationship.

The 2 arm and student are a combination (student arm, to be exact), and the conclusion is that student will inevitably have 2 arm, and student is responsible for the life cycle of the 2 arm, assuming student death arm will die.

In the comprehensive. The text under this picture is simply unfounded. If one wants to eat, can we conclude that we want to be eaten by him?

The fallacy of association, composition, and aggregation in Java Madness handout