iOS design mode-UML inter-class relationship refinement

Before formally designing patterns, it is necessary to introduce the relationship between UML class diagrams, because some tutorials, books, including my post, will use a lot of class diagrams to describe the relationships between the various classes. This is a very intuitive, minimalist way.

Of course, the ability and energy are limited, the introduction of the UML here is only limited to a few common inter-class relationships.

Include: inheritance, implementation, dependency, association, aggregation, composition

Before the second, if you do not understand the class diagram, you can first look at the article I wrote earlier: A detailed description of eight UML class diagram symbols

IOS-UML relationship between classes by Colin,

Reprint Please specify source: http://blog.csdn.net/hitwhylz/article/details/40372781

One. Inherited

Refers to the ability of a class (called a subclass, sub-interface) to inherit the functionality of another class (called the parent class, parent interface) and to increase its own new functionality, which is the most common relationship between a class and a class or interface and interface;

In Objective-c, this kind of relationship is passed: Clear identification, at design time is generally not controversial;

UML Class diagram: (represented by a hollow triangle + implementation.) Direction from sub-class to parent class)

Here comes the iOS class inheritance diagram:

Two. Realize

A class class implements the function of the interface interface (which can be multiple), and the implementation is the most common relationship between the class and the interface;

UML class diagram (denoted by a hollow triangle + dashed line). Point to interface from Class)

Three. Depend on

It can be simply understood that a class A is used to another class B, and that the use of the relationship is contingency, temporary, very weak, but the B-class changes will affect A; For example, a person needs to cross a river, need to borrow a boat, when the relationship between man and ship is dependent, such as people need oxygen to metabolism, Then people rely on oxygen, and they are dependent.

At the code level, for Class B as a parameter is used by Class A in a method;

UML class diagrams (denoted by dashed arrows, from dependent [person] to dependent [oxygen], note: The code shows oxygen as a parameter in the human metabolic method, such as: + Metabolism (Ino2: oxygen))

Four. Association

He embodies a strong dependency between the two classes, or the semantic level of the class and interface, such as me and my friends; this relationship is more than dependence, the contingency of no dependency, the relationship is not temporary, generally long-term, and the relationship between the two sides is generally equal, the association can be one-way, two-way;

At the code level, the associated class B appears as a class attribute in the association Class A, or the association Class A refers to a global variable of the type being associated with Class B;

UML class diagrams (denoted by implementation arrows)

Five. Polymerization

Aggregation is a special case of association relationship, he embodies the whole and part, the relationship of ownership, that is, the relationship between the whole and the part is has-a, they can have their own life cycle, some can belong to multiple whole objects, can also be shared for multiple whole objects, such as computer and CPU, The relationship between company and employee, etc.;

Performance at the code level, and the association is consistent, can only be differentiated from the semantic level, that is, the association Class B in the form of a class attribute in the association Class A, or the association Class A refers to a type is associated with the class B global variables;

UML class diagram (denoted by a hollow diamond + solid Arrow)

Six. Combination

The combination is also a special case of the relationship, he embodies a contains-a relationship, which is stronger than aggregation, also known as strong aggregation, he also embodies the relationship between the whole and part, but at this time the whole and part is not divided, the whole life cycle end also means that part of the life cycle end , like you and your brain;

Performance at the code level, and the association is consistent, can only be differentiated from the semantic level, that is, the association Class B in the form of a class attribute in the association Class A, or the association Class A refers to a type is associated with the class B global variables;

UML Class diagram: (represented by a solid diamond + solid arrow, both ends can have numbers.) For example, 1 people have 1 brains, the ends of which are 1, 1)

There is little doubt about inheritance and realization of these two relationships, they embody a kind of class and class, or the vertical relationship between class and interface;

The other four relations are the class and class, or the class and interface between the reference, the horizontal relationship, is more difficult to distinguish between a lot of things to prepare for positioning is difficult, mentioned earlier, these relationships are semantic level, so from the code level and can not completely distinguish between the various relations;

However, in general, the following relationships show the degree of strength: Combination > Aggregation > association > dependency;

Here is a careful comparison:

1. Aggregation and Combination
(1) Aggregation and combination are a kind of binding relationship, but the extra has a whole-part meaning.

(2) different life cycle of parts

In an aggregation relationship, the entire piece does not have a life cycle of the part, so the part is not deleted when the whole piece is deleted. Furthermore, multiple pieces can share the same part.
In a composite relationship, the entire piece has a life cycle of the part, so the part must be deleted when the whole piece is deleted. Also, multiple pieces cannot share the same part at the same time.

(3) The aggregation relationship is a "has-a" relationship, and the combined relationship is a "contains-a" relationship.

2. Associations and Aggregations
(1) Performance at the code level, and the association is consistent, can only be differentiated from the semantic level.

(2) The difference between association and aggregation is mainly semantically, and the associated two objects are generally equal, for example, if you are my friend, aggregation is generally not equal.

(3) Association is a structured relationship in which an object is associated with another object.

(4) Association and aggregation are depending on the problem domain, for example, in the field of concern about the car, the tyre must be combined in the car class, because it has no meaning to leave the car. But in the business of selling tires, even if the tires leave the car, it makes sense, and it can be aggregated.

3. Associations and Dependencies
(1) in association, it is a kind of strong dependency between the two classes, or the semantic level between the class and the interface, such as me and my friends; this relationship is more than relying on the contingency, the relationship is not temporary, generally long-term, and the relationship between the two is generally equal.

(2) In the dependency relationship, it is simple to understand that a class A uses another Class B, which is contingent, temporary, and very weak, but changes in class B affect a.

4. Comprehensive comparison
These relationships are semantically level, so it is not possible to completely differentiate the relationships from the code level, but in general, the latter relationships are shown in the following ways:

Combination > Aggregation > Correlation > dependencies;

Here's a simple example that distinguishes between aggregation and combinatorial relationships.

Wild geese like the lively fear of loneliness, so they have been living in a gregarious life, so that there are geese flock every goose has its own flock of geese. Every wild goose has a lot of geese, the relationship between the wild goose and the flock can be called aggregation.

In addition each goose has two wings, the relationship between the wild Goose and the Wild Goose Wings is called the combination. It can be seen that the relationship between the aggregation is obviously not tightly knit, the geese will not be able to survive because of their group of geese, and the wild Goose wings can not be separated from the wild Goose and live alone-the group relationship of the class has the same life cycle.

Aggregation diagram:

Composition diagram:

Code performance:

Flock of wild Goose class:

public class Goosegroup    {public Goose Goose;        Public Goosegroup (Goose Goose) {this.goose = Goose; }    }

Wild Goose Category:

    public class Goose    {public        Wings Wings;        Public Goose ()        {            wings=new wings ();        }    }

The class in the aggregation relationship contains another class as a parameter
Wild Geese (Goose) are used as parameters to pass the values in the Goosegroup (The Wild Goose Class) (Goose) can be separated from the wild Goose class and exist independently.
The class that combines the relationships contains the instantiation of another class
Wild Goose (Goose) before instantiating, be sure to instantiate the Wings Class (Wings) Two classes tightly coupled together they have the same life cycle Wing class (Wings) can not be separated from the Wild Goose Class (Goose) and independent existence
The encapsulation of information is different
In the aggregation relationship, the client can know both the wild Goose and the wild goose, because they are independent
But in the combinatorial relationship, the client only knows the Wild goose class, does not know the existence of the wing class, because the wing class is tightly encapsulated in the Wild Goose class.

That's roughly the case. Of course, this is only part of the UML. If you are interested, you can learn in depth.

Study on the road, with June encouragement

iOS design mode-UML inter-class relationship refinement