UML class diagram and object-oriented design principles

1. Introduction

It has been two years since I began to learn programming from a freshman year. From the initial study of the Html,js,javese, to Javaee,android, I can also write some toys. The learning process also unconsciously understood some of the so-called design Patterns , and now intends to learn the system.   Learn to book the art of Design mode----------------------the software developer.

The so-called design patterns, that is, the predecessors of a similar problem of the abstract solution . The Gof +1 (simple Factory mode) design pattern is given in the book. Each mode of learning will focus on the following points: name , problem (problem), solution (solution), effect ( consequence).

2. UML

(1) Overview

Learn from UML first.

From its full name Unified Modeling language can be seen that it is an analytical design language (modeling language).

There are several parts of a view , a diagram (Diagram), a model element , a communication mechanism (general mechanism).

(2) class diagram

The properties and methods of the class are represented as follows:

Visibility attribute Name: type [= default value]

Visibility method Name (parameter list) [: Return value type]

Examples are as follows:

(3) The relationship between classes

① Association Relationship

1) bidirectional correlation. examples are as follows:

2) One-way association. Examples are as follows:

3) Self-correlating. Examples are as follows:

4) Multiple sexual associations. Examples are as follows:

5) Aggregation relationship. Examples are as follows:

6) combined relationship. Similar to the aggregation relationship, the difference is that the composite relationship emphasizes a dependency (parasitic) relationship. Examples are as follows:

② dependency Relationships. Examples are as follows:

The draw method of the view class relies on the ingress of the canvas class.

③ Generalized relationships (inheritance relationships). Examples are as follows:

④ interface and implementation relationship. Examples are as follows:

3. Object-Oriented design principles

① Single Responsibility Principle

A class is responsible only for the corresponding responsibilities in a functional area. Or, in the case of a class, there should be only one cause for it to change.

The purpose of single duty principle is to realize high cohesion and low coupling, and its core idea is that a class cannot be too "tired". In a software system, the more responsibilities a class has, the less chance it will have to be reused.

As in the following example: The Customdatachart class takes on too much responsibility: it is responsible for connecting to the database, for getting query clients, and for displaying charts. A reasonable approach is to be divided into 3 categories:

1) Dbutil: Contains connection database method getconnection ();

2) Customdao: Contains the Find Customs Method Findcustoms () method;

3) Customdatachart: Contains the method of displaying the chart displaychart ();

The reconstructed structure diagram is as follows:

The benefits of refactoring are obvious: we divide the methods of different responsibilities into different classes to facilitate reading comprehension; When a responsibility changes, such as replacing a database, we only need to modify the getconnection () method in Dbutil, while the rest of the code is unchanged.

② Opening and closing principle

A software entity should be open to extensions and closed for modifications. That is, the software entity should be extended without modifying the original code.

Any software is faced with a very important problem, that is, demand will change over time. However, faced with new requirements, the software should try to ensure the stability of the original system, without modifying the original system code in the case of adding a new extension module.

The principle of substitution of ③ Richter

It is strictly defined as follows:

An object of type S, O1, has an object O2 of type T, so that all program P defined by T has no change to the behavior of the program p when all objects O1 are substituted for O2, then the type S is a subtype of type T.

Its popular version is defined as:

All places where the base class is applied (the parent class) must be able to be replaced with its subclasses.

That is, when we are programming, we should be programming for interfaces .

④ Dependency Reversal principle

Abstractions should not be dependent on detail, and detail should be dependent on abstraction. In other words, interfaces should be programmed rather than implemented for implementation.

When we are programming for the abstraction layer, we inject the object of the specific class into the way of dependency injection. Common injection methods are: Construction injection, SetPoint injection and interface injection.

⑤ Interface Isolation principle

To use as many specialized interfaces as possible instead of using a single total interface, the client should not rely on interfaces that it does not need.

The principle of ⑥ synthesis multiplexing

Try to use a combination of objects rather than inheritance to achieve the purpose of reuse.

⑦ Dimitri Law

A software entity should be as small as possible with other software entities.

UML class diagram and object-oriented design principles