Vernacular design--from the class relation

Restudying, recently more research and development of various types of library, the design is some feelings. When I was in college, although I knew it, but it was always inexperienced, now I try to say it in the most understandable way.

is the so-called design not the right way to organize the relationship? So I think the first thing to do is to start with the relationship between classes.

In Java development, there are many times we are constantly dealing with the relationship between classes and classes, of which six relationships are: dependency, association, aggregation, composition, inheritance, implementation, their coupling degree is enhanced, and its representation in UML is as follows:

Let's explain these relationships separately.

Depend on

In real life we do almost anything with the help of other objects, in other words, we rely on other things to live. For example: Xiao Ming to drive, Xiao Ming to Eat, Xiao Ming to live and so on, it is not difficult to imagine that the dependence of the relationship is the most common in the real world. For the language world of object-oriented thinking, dependence is also the most prevalent and common relationship.

At the code level, the dependency is represented as a function parameter.

publicclass Person{    publicvoiddrive(Car car){        //    }}

UML represents:

Association

If the dependence on the temporary, contingency, then the association is a lasting relationship. Why do you say that?
Xiao Ming eat with chopsticks, this relationship only exists in the case of Xiao Ming, once Xiao Ming does not eat, then this dependence is terminated.
Unlike dependency, the relationship between the two sides of the object has a long-term, fixed correspondence, that is, association is a strong dependency. Association relationships are divided into two types: one-way and two-way associations. The so-called one-way Association popular point is "You have me, but I may not have you", such as Xiao Ming owns a car (note and Xiao Ming Drive to distinguish), but the car this object does not own you ah. And one-way correlation is a two-way association, that is, "You have me, I have you," such as a couple is a two-way association.

At the code level, the association behaves as an object as a member variable of another class.

One-Way Association

publicclass Person{    private Car car;    publicvoidsetCar(Car car){        this.car=car;    }}

UML represents:

Bidirectional correlation

publicclass Husband{    private Wife wife=new Wife();    publicvoidsay(){        System.out.println("my wife name:"+wife.getName());    }}publicclass Wife{    private Husband husband=new Husband();    publicvoidsay(){        System.out.println("my husband name:"+husband.getName());    }}

UML represents:

Polymerization

The relationship of aggregation is a strong association, the difference between the two is the semantics: the relationship between the aggregation is more like "whole-part", a bit of the meaning of assembly, and the relationship between the objects are independent of each other, there is no assembly relationship.
In the real world, molecules are made up of atoms, cars are made up of a variety of components, and this is the best description of the aggregation relationship. It is important to note that the atoms that make up a type of molecule can also form a molecule of type B, what does that mean? That part can exist alone, In other words, the life cycle of both the whole and the part is not synchronous. For example: Water molecules are composed of oxygen atoms and hydrogen atoms, you cannot say that no water molecules have no oxygen atoms and hydrogen atoms bar.

At the code level, the aggregation and association are both in the same form and are represented as member variables.

publicclass Car{    private Tyre tyre;    private Engine engine;    publicvoidsetTyre(Tyre tyre){        this.tyre=tyre;    }    publicvoidsetEngine(Engine engine){        this.engine=engine;    }}

UML represents:

Some people are written like this:

publicclass Car{    private Tyre tyre=new Tyre();    private Engine engine=new Engine();}

I look at the code level to meet Ah, then this is not an aggregation relationship? First of all, we must say that this is an aggregation relationship. But it's just a matter of aggregation. Why do you say that?

We abstract the concept of automobiles from the real world and turn it into car in the software world, which is also advocated in Java for object-oriented programming, but in this process from the real world to the software world, it is necessary to ensure that the static and dynamic properties of the object have not changed. What do you mean, in other words, You turn real-world cars into cars in the software world, and, in turn, make sure that car from the software world translates into real-world automobiles. If the conversion is not guaranteed to be consistent, then there is a problem in the abstraction process.

Now the car in the top of the code is turned into a real-world vehicle, and we find that the converted car can't change the wheels? It's possible? Obviously, there is a problem in the process of the abstract car-to-car class. So what should I do?
In addition to what we wrote at the outset, it can be as follows:

publicclass Car{    private Tyre tyre=new Tyre();    private Engine engine=new Engine();    publicvoidsetTyre(Tyre tyre){        this.tyre=tyre;    }    publicvoidsetEngine(Engine engine){        this.engine=engine;    }}

Combination

Composition and aggregation are very similar, all of which represent the "whole-part", but the combination requires that the whole and part of the life cycle be synchronous, and that part cannot be separated from the whole. It is not difficult to find that a combination is a strong aggregation relationship. For example, the human body is made up of different organs, in which we take the heart, and , the heart can not be separated from the human body, the two will die once separated.
At the code level, it usually behaves as a member variable of a class, which in addition requires that the member variable be created in the constructor.

publicclass People{    private Heart heart;    publicPeople(){        heart=new Heart();    }}

UML represents:

By now we understand the four relationships of dependency, association, aggregation, and composition from a microscopic perspective, and in macro terms, these four relationships embody the dependencies between objects and objects, so in some ways we also rely on them to cover these four relationships. In many articles, and did not mention this, which also caused, in many cases, We were puzzled by the way these concepts were being ground.

From the real world, the relationship between objects and objects can be divided into two categories, one is the above macro-said the dependence , the other is we want to talk about the generalization

Generalization

Before you begin to explain generalization, start with extends:

Extends means extending, extending, inheriting. From the perspective of this word, subclasses should be divided into two meanings:

One is to enhance the function of the original class, which embodies not the "father and son" relationship of the biological world. For example, I now have a tool class tools, and now I want to enhance the tool class, according to the open and closed principle, I define UpdateTools extends Tools , at this time you can not say Updatetools is tools "children", Because you find that the updatetools here is only to enhance the functionality of the original tools class as a function extension class. At this point, we call this extension more appropriate.

The other is to embody the "father and son" of the biological world, that is, the subclass and the parent class behave differently in certain behaviors or properties. At this time, the word inherit to indicate more appropriate, that is, we often say the meaning of inheritance.

By now, I believe you have understood the meaning of extends. In fact, in practice, we use the purpose of inheritance is to expand, therefore, can not do the drill.
The reason for this is that one of the interns brought in last year simply didn't understand the two levels of extends and felt that it was problematic to expand tools through Updatetools.

Here we are speaking generalization.
Generalization represents a relationship between a class (parent class or interface) and one or more of its variants. In simple terms, generalization represents the extension between classes and classes, the expansion of interfaces and interfaces, and the implementation relationship between classes and interfaces.
In Java, you use extends to represent extensions, and implements to implement relationships.

Extended:

publicclass Tools{    publicvoidprint(){        //do     }}publicclass UpdateTools extens Tools{    publicvoidprintError(){        //do    |}

Inherited:

publicclass Father{    publicvoidgetName(){        //do    }}publicclass Son{    publicvoidother(){        //do    }}

UML represents:

Realize:

publicinterface UserService{    void execute();}publicclass UserServiceImpl implements UserService{    @override    void execute(){        //do    }}

UML represents:

Vernacular design--from the class relation