Difference between Composition and Dependency in c

问题:

I know, somebody had asked the same question about this case, but i still don't really get it, i need a specific answer. Thank you :D

回答1:

Since Gangnus did not correctly explain the meaning of composition, I'll have to do it.

As explained by Gangnus, an aggregation is a special form of association with the intended meaning of a part-whole-relationship, but without a precise semantics (the UML spec says: "Precise semantics of shared aggregation varies by application area and modeler"). For instance, we can model an aggregation between the classes Carand Engine and between the classes Courseand Lecture since an engine is part of a car and a lecture is part of a course.

A composition (also called "composite aggregation" in the UML spec) is a special form of aggregation, where a component instance is part of at most one aggregate instance at a time (that is, it cannot be shared between several aggregates). This means that the aggregation between Carand Engine is a composition (because an engine cannot be shared between two cars at the same time), while an aggregation between Courseand Lecture is not necessarily a composition since a lecture can be shared among two courses (e.g. a database management course and a software engineering course could share a lecture on UML). This implies that the multiplicity of a composition's association end at the aggregate side is either 1or 0..1, while it may be also * in the case of a non-composite aggregation.

In addition to this main characteristics of a composition (to have exclusive parts), a composition may also come with a life-cycle dependency between an aggregate and its components implying that when an aggregate is deleted, all of its parts are deleted with it. However, this only applies to some cases of composition, and not to others, and it is therefore not a defining characteristic. The UML spec states: "A part may be removed from a composite instance before the composite instance is deleted, and thus not be deleted as part of the composite instance." In our example of the Car-Engine composition, it's clearly the case that the engine can be removed from the car before the car is destroyed, in which case the engine is not destroyed and can be re-used.

回答2:

These things are far from each other.

A- - - ->B  Dependency 

is the most common thing. It means, that code of A is beware of class B. And a change in B members visible to A could require a change in A.

A------->B association (with none aggregation)

Association is more close connection. The association can have different levels of closeness, but even on the weakest one it must have at least one navigability arrow. (if they are both sided, they are not shown) It means, that there exists some easy way to point from A to B. For example, there exist a construction as a.x.y.b. The association has such attribute as aggregation. It could be none, shared, composition.

A<>------>B  association (with shared aggregation) 

Shared has NO strict definition, it is left to us modelers and tools authors. But usually it shows that A instance or class in some sense has some instances of B.

A♦------>B  association (with composite aggregation or simply 'composition') 

It has strict definition - that means, that A or its instance has instances of B. It also implies, that these B's exist only in the borders of this association. When the association or its owned will be destroyed, there will be NO access to these B's. If these strict demands are not fulfilled, it is NOT a composition.

Citation from UML standard 2.5: "Composite aggregation is a strong form of aggregation that requires a part (see 11.2.3) instance be included in at most one composite instance at a time. If a composite instance is deleted, all of its parts are normally deleted with it."

Other variants for associations and dependencies also exist.

So, dependency is an ancestor of the owner of composition.

回答3:

It is very simple. Dependency is type of directed relationship which has no runtime semantic implication. It says that definition of one element (source of dependency) is either semantically or structurally dependend on the definition of the target element. No runtime semantic implication means that there is not instance in real world. (e.g. people dependend on somethig cannot be connected by dependency in the model :)

Composition is an association of composite aggregation type.It can have an instance (runtime semantic implication) To be more accurate, it is property element on assocaition end set as composition. You can find compositions anywhere in the world. Good example is human body ... it is composition of head, arms, legs,... Parts cannot be physically connected to other composition of the same type. Human body exists if it's parts exist as well.