1, the preface

I believe that many students will encounter a variety of class diagrams in the process of learning design patterns, and they are very consistent in the way to understand, skip the class diagram, directly look at the code. As you learn more about design patterns, you will find that UML is actually the soul of a design pattern. A UML class diagram can summarize the idea of design patterns, as well as the subsequent code. Therefore, let’s learn UML today as an introduction to design patterns

2. Basic concepts

UML(Unified Modeling Language) is a standard Language for the specification, visualization, and documentation of products of object-oriented systems. It is a non-patented third generation Modeling and specification Language. UML is a modeling tool for object-oriented design, independent of any specific programming language.

If the above definition is a little vague, it is my personal understanding that UML class diagrams are modeled in the form of diagrams, transforming literal descriptions into diagram definitions. Just like when we look at the curve or bar chart of the data trend, we can hardly see the effect by looking at the data, but we can understand it more deeply by turning it into a chart

3. Basic properties of the class diagram

3.1. Composition of UML class diagram

Let’s use a Person class to introduce the attributes of a UML class diagram

public class Person {

    public String name;

    private int age;

    protected Double weight;
    
    private int sex = 0;

    public void setName(String name) { this.name = name; }

    public String getName(a){ return name; }

    private String eat(String food){ return "Eat" + food; }

    protected int age(a){ returnage; }}Copy the code

A UML class diagram is a rectangle divided into three cells in which

  • The first cell: represents the class/interface name

  • Second cell: represents the attribute information and permissions of the class

    • The format is: Permission Attribute Name: Type [= default]

  • Third cell: represents the methods of the class along with permissions and return information

    • The format is: Permission method name (parameter list) [: return type]

  • The three common permissions are as follows:

    • + said public
    • – said private
    • # said protected

3.2 relationships between UML class diagrams

I believe that seeing this, you have your own understanding of the class diagram, now we continue to understand the other content of UML class diagram, the relationship between class diagrams.

3.2.1 generalization Relation (inheritance relation)

The so-called Generalization relationship represents the Generalization relationship between classes and interfaces, and is represented by hollow triangle + solid line, and the arrow points to the parent class

Personal understanding: Inheritance is a relationship of what, like students, teachers belong to the category of people; Man, bird and beast belong to the category of animals

Code representation: Extends extends

Example:

Student and Teacher inherit from the parent class Person

3.2.2. Realize relationships

The Realization relationship is the same as our implementation relationship between a class and an interface in real development, represented by a hollow triangle + dashed line with an arrow pointing to the interface

Personal understanding: realization is a kind of what relationship, like the student has the right to study nine years of compulsory education, the teacher has the welfare of the state’s teacher subsidy, etc.

Implements implements interface

Example:

Here we assume that there is an interface IRight, which defines a right() method, which returns what rights the user has, and then the Student and Teacher implement this interface

public interface IRight{
    String right();
}
Copy the code

3.2.3 Association relationship

The so-called Association relationship is more like an owned relationship, associating two independent objects, one class knows the properties and methods of the other class, represented by a solid line tip

Personal understanding: Just like the student and the class director is a fixed relationship, the student records the information of the head teacher, the head teacher has the list of students

Code: one class is a member variable of another

Example:

For the students, the students depend on the head teacher, and for the head teacher, the head teacher depends on the students. Because it is a two-way relationship, it can be directly represented by a solid line without a tip

3.2.4 Aggregation relationship

The so-called Aggregation relationship emphasizes the relationship between the whole and the parts. The whole has a part (HAS-A), which is represented by a hollow diamond and a solid point. The diamond points to the whole and the point points to the part

Personal understanding: Just like our clothes, our clothes have clothes, pants, hats, etc., which are optional for people, even if they do not have it will not affect, that is, the life cycle of people is different from the life cycle of clothes

Code: one class is a member variable of another

Example:

3.2.5. Combination relationship

The so-called Composition relationship also emphasizes the relationship between integration and parts, but it is more accurate to say that the whole contains part, which is represented by solid diamond + solid point. The diamond points to the whole, and the point points to the part

Personal understanding: Just like the relationship between the company and the department, there is no department without the company, the department and the company coexist, namely: the life cycle of the two is consistent

Code: one class is a member variable of another

Example:

3.2.6 Dependencies

The so-called Dependence relationship is a weak one, represented by dotted arrows with the tip pointing to other dependent parties

For example, students need to use a pass to attend a lecture. After using the pass, they will not use it. The next time they will use another pass to attend a lecture

Code: one class is another class’s local variables, method parameters, etc

Example:

public class Certificate {

    String name;

    public Certificate(String name) {
        this.name = name;
    }
    public Boolean entrance(a){
        return true; }}public class Student {

    private String name;

    private int age;

    // Method parameters
    public Boolean entranceByCertificate(Certificate certificate){

        if (certificate==null) {
            return false;
        }
        returncertificate.entrance(); }}Copy the code

From Student to Certificate

3.3. The strength of the relationship

I believe that we have recognized all kinds of relationships here. There is no need for the author to elaborate too much on the strength of the relationship. Through reading the article, it can be seen that the following order of the article is just the strength of the relationship between UML class diagrams.

Generalization relationships = Implementation relationships > Association relationships > aggregation relationships > Composition relationships > dependencies

The points at issue here are:

Generalization relation = implementation relation, should be changed to generalization relation >= implementation relation, both from the code level analysis generalization (inheritance) is a little stronger than implementation, here the author will not do too much elaboration, interested readers can study by themselves.