IOS design patterns-(2) UML inter-class relationships

IOS design patterns-(2) UML inter-class relationships

Before formally speaking about the design mode, it is necessary to introduce the relationship between UML class diagrams, because class diagrams will be widely used in some tutorials, books, including my subsequent articles, describes the relationships between classes. This is an intuitive and simple method.

Of course, the capabilities and energy are limited. The introduction of UML here is only limited to the relationship between several common classes.

Including:Inheritance, implementation, dependency, association, aggregation, and combination

 

 

Before that, if you do not understand the class diagram, you can read an article I wrote earlier: Describes the representation of the eight UML class diagram symbols.

 

 

 

 

 

I. Inheritance

 

A class (called a subclass or sub-interface) inherits the functions of another class (called parent class or parent interface) and can add its own new functions, inheritance is the most common relationship between classes or interfaces;

In objective-c, such relationships are identified by clear identifiers, which are generally not controversial during design;

 

UML class diagram: (expressed by a hollow triangle + implementation. Direction from subclass to parent class)

 

Here comes the iOS class inheritance diagram:

 

 

 

II. Implementation

 

It refers to the function of a class to implement interface interfaces (multiple interfaces can be implemented); implementation is the most common relationship between classes and interfaces;

UML class diagram (represented by a hollow triangle + dotted line. From class to interface)

 

3. Dependency

 

It can be simply understood that A class A uses another class B, and this relationship is contingent, temporary, and very weak, however, changes in Class B will affect A. For example, if someone wants to cross the river and borrow A ship, the relationship between people and the ship is dependent. For example, A person needs oxygen for metabolism, then people depend on oxygen, and they are dependent on each other.

As shown in the code, Class B is used by Class A in A method as A parameter;

 

UML diagram (represented by a dotted arrow, from dependent [persons] to dependent objects [oxygen]. Note: The code shows oxygen as a parameter in human metabolism, for example: + metabolism (ino2: Oxygen ))

 

4. Association

 

It represents a strong dependency between two classes or between classes and interfaces, such as my friends and I; this relationship is more dependent than the dependency relationship, with no dependency relationship. The relationship is not temporary and is generally long-term. In addition, the relationship between the two parties is generally equal, and the relationship can be one-way and two-way;

It is manifested in the Code layer. For associated Class B, it appears in the form of class attributes in associated Class, it may also be that associated Class A references A global variable of the associated Class B;

 

UML class diagram (represented by the Implementation arrow)

 

 

5. Aggregation

 

Aggregation is a special case of association. It reflects the relationship between the whole and the part, that is, the relationship between has-a. At this time, the whole and the part can be separated, they can have their own lifecycles, some of which can belong to multiple objects, or share multiple objects, such as the relationship between computers and CPUs, and between companies and employees;

It is manifested in the Code layer. It is consistent with the association relationship and can only be distinguished from the semantic level. That is, associated Class B appears in associated Class A in the form of class attributes, it may also be that associated Class A references A global variable of the associated Class B;

 

UML class diagram (represented by hollow diamond + solid arrow)

 

Sat. Combination

 

A combination is also a special case of association. It represents a contains-a relationship, which is stronger than aggregation, also known as strong aggregation; it also shows the relationship between the whole and the part, but the whole and the part are inseparable at this time, and the end of the overall life cycle means that part of the life cycle ends; for example, you and your brain;

It is manifested in the Code layer. It is consistent with the association relationship and can only be distinguished from the semantic level. That is, associated Class B appears in associated Class A in the form of class attributes, it may also be that associated Class A references A global variable of the associated Class B;

 

UML class diagram: (expressed by solid diamond + solid arrow, there can be numbers at both ends. For example, if one person has one brain, the two ends are 1, 1)

 

 

There is no doubt about the relationship between inheritance and implementation. They reflect the vertical relationship between a category and a class, or between a class and an interface;

The other four relationships reflect the reference and horizontal relationships between classes and classes, or between classes and interfaces, which is difficult to distinguish, there are many relationships between things. It is very difficult to prepare for positioning. As mentioned above, these relations are all semantic-level, so they cannot be fully differentiated from each other at the code level;

In general, the strength of the last several relationships is: Combination> aggregation> association> dependency;

The following is a detailed comparison:

 

 

 

1. Aggregation and combination
(1) Aggregation and combination are a combination, but they only have an additional meaning of the whole-part.

(2) Different parts have different lifecycles.

In the aggregate relationship, the whole part does not have the life cycle of the part, so the part will not be deleted when the whole part is deleted. In addition, multiple parts can share the same part.
In the composite relationship, the whole part has the life cycle of the part. Therefore, when the whole part is deleted, the part will be deleted. In addition, multiple parts cannot share the same part at the same time.

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

2. Association and aggregation
(1) It is represented at the code level and is consistent with the association. It can only be distinguished at the semantic level.

(2) The difference between Association and aggregation is mainly in terms of semantics. The two objects associated are generally equal. For example, if you are a friend of mine, aggregation is generally not equal.

(3) Association is a structured relationship, that is, an object is associated with another object.

(4) Association and aggregation depend on the problem domain. For example, tires must be combined in the automobile field, it makes no sense when it leaves the car. However, in the shops where tires are sold, even if the tires leave the car, it makes sense, and this can be aggregated.

3. Association and dependency
(1) A strong dependency between two classes or between classes and interfaces, such as my friends and I; such a relationship is more dependent than the dependency, and does not have any dependency relationship. The relationship is not temporary and generally long-term, and the relationship between the two parties is generally equal.

(2) In dependency relationships, we can simply understand that A class A uses another class B, and this relationship is contingent, temporary, and very weak, but changes in Class B will affect.

4. comprehensive comparison
These relationships are semantic-level, so they cannot be fully differentiated from each other at the code level. However, in general, the strength and weakness of these relationships are as follows:

Combination> aggregation> association> dependency;

 

 

The following is a simple example to differentiate the relationship between aggregation and combination.

Geese like to live and fear loneliness, so they have lived in a group, so that each of them has its own group. Each wild goose group has many geese. The relationship between them can be called aggregation.

In addition, each wild goose has two wings. The relationship between the wild goose and the wild goose wings is called combination. It can be seen that the relationship of aggregation is obviously not closely combined, and the geese cannot survive because their Group Owners disband the geese, however, yundun cannot survive independently from the yundun-the composite class has the same lifecycle.

 

Aggregation relationship diagram:

Combination relationship diagram:

Code performance:

Geese:

 

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

 

Geese:

 

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

The aggregate link class contains another class as the parameter.
In the GooseGroup constructor, Goose is used as a parameter to pass in the value. Goose can exist independently of the geese.
Classes in the composite relationship contain the instantiation of another class.
Before instantiating Goose, you must first instantiate the Wings class (Wings). The two classes are closely coupled. They have the same life cycle Wings class (Wings) it cannot exist independently from Goose
Different information Encapsulation
In the aggregation relationship, the client can understand both the geese and geese at the same time, because they are independent
In the composite relationship, the client only recognizes the geese and does not even know the existence of the wings, because the wings are tightly encapsulated in the geese.

 

 

 

This is basically the case. Of course, this is only part of UML. If you are interested, you can study in depth.

 

On the way to learning, I will share with you