Design Mode Notes-A basic introduction to design modes

Posted Jun 27, 20207 min read

In software engineering, as the software has more and more functions, the amount of code in the corresponding software will also increase. At this time, the complexity of the software will increase, and the code will also be reusable and readable. Issues such as scalability and scalability. To solve these problems, you need to use design patterns.
Before talking about specific design patterns, first introduce the principles of design patterns. Each design pattern is a concrete manifestation of the principles of design patterns. The following instructions are all in the programming language Java

  1. Seven principles of design patterns

1.1 Single Responsibility Principle

For classes, a class should only be responsible for one responsibility. Such as category A is responsible for two different responsibilities:responsibilities 1, responsibilities 2. When the requirements of responsibility 1 change and change A, it may cause the execution error of responsibility 2, so the granularity of class A needs to be decomposed into A1, A2

1.2 Interface isolation principle

The dependence of one class on another should be based on the smallest interface
for example:

Class A depends on class B through interface Interface1, and class C depends on class D through interface Interface1. If interface Interface1 is not the smallest interface for class A and class C, then class B and class D must implement methods that they do not need. According to the principle of isolation, it should be handled as follows:Interface1 is split into several independent interfaces, and Class A and Class C respectively establish dependencies with the interfaces they need. That is, the principle of interface isolation

1.3 Dependency reversal principle

The Dependence Inversion Principle refers to:1) High-level modules should not depend on low-level modules, both should rely on their abstractions 2) Abstractions should not depend on details, details should depend on abstractions 3) The central idea of relying on inversion(inversion) It is interface-oriented programming. 4) The principle of reliance on inversion is based on the design concept:relative to the variability of details, abstract things are much more stable. Architectures built on abstractions are more stable than those based on details. In Java, abstract refers to the interface or abstract class, and the details are the specific implementation class. 5) The purpose of using the interface or abstract class is to formulate a good specification without involving any specific operations, and leave the task of showing details to them. Implementation class to complete

1.4 Richter Substitution Principle

In object-oriented, inheritance contains such a layer of meaning:all the methods that have been implemented in the parent class are actually setting specifications and contracts. Although it does not require all subclasses to follow these contracts, if the subclasses Any modification of these implemented methods will cause damage to the entire inheritance system. While inheritance brings convenience to programming, it also brings disadvantages. For example, the use of inheritance will bring intrusion to the program, reduce the portability of the program, and increase the coupling between objects. If a class is inherited by other classes, when this class needs to be modified, all subclasses must be considered. , And after the parent class is modified, all the functions related to the subclass are likely to cause problems. In programming, how to use inheritance correctly, you need to use the Richter principle.
The Liskov Substitution Principle was proposed in 1988 by a lady from the Massachusetts Institute of Technology. If for each object o1 of type T1, there is an object o2 of type T2, so that when all the programs P defined by T1 are replaced by o2 in all objects o1, the behavior of the program P does not change, then the type T2 is a subtype of type T1. In other words, all references to the base class must be able to transparently use the objects of its subclasses. 3) When using inheritance, follow the Liskov Substitution Principle, try not to override the parent class method in subclasses
The Liskov Substitution Principle tells us that inheritance actually enhances the coupling between the two classes. Under appropriate circumstances, you can use aggregation, combination, and dependency to solve the problem.
1.5 Opening and closing principle
The Open Closed Principle is the most basic and most important design principle in programming. A software entity such as a class, module, and function should be open to extension(to the provider) and closed to modification(to the user). Construct the framework with abstraction, and use the implementation to expand the details. When the software needs to change, try to achieve the change by expanding the behavior of the software entity, rather than by modifying the existing code.

1.6 Dimit's Law

The Demeter Principle(Demeter Principle) is also called the principle of least knowledge, that is, the less a class knows about the class it depends on, the better. In other words, no matter how complicated the dependent class is, try to encapsulate the logic inside the class. In addition to the public methods provided, no information is disclosed to the public

1.7 Synthetic multiplexing principle

Synthetic reuse principle try to use synthesis/aggregation instead of inheritance

Core principles of design principles

1) Identify possible changes in the application, separate them out, and do not mix with the code that does not need to be changed.
2) For interface programming, not for implementation programming.
3) Efforts to design loose coupling between interactive objects

Second, the UML class diagram and the relationship between classes and classes

In the above introduction, there are multiple pictures representing classes and classes, which is also called UML class diagram
UML Unified modeling language UML(Unified Modeling Language) is a language tool used for software system analysis and design. It is used to help software developers think and record the results of ideas. UML itself is a set of symbols Provisions, just like mathematical symbols and chemical symbols, these symbols are used to describe the various elements in the software model and their relationships, such as classes, interfaces, implementation, generalization, dependencies, composition, aggregation, etc.
It can be found that to understand the UML diagram, you also need to know the relationship between classes and classes

  1. Dependency
    As long as another class is used in the class, there is a dependency relationship between them. If there is no other class, even the compilation can not pass.
    Code example

    public class PersonServiceBean {
    private PersonDao personDao;//Class
    public void save(Person person){}
    public IDCard getIDCard(Integer personid){}
    public void modify(){
    Department department = new Department();
    public class PersonDao{}
    public class IDCard{}
    public class Person{}
    public class Department{}

Corresponding class diagram
2. Generalization
The generalization relationship is actually the inheritance relationship, which is a special case of the dependency relationship

public abstract class DaoSupport{
public void save(Object entity){
public void delete(Object id){
public class PersonServiceBean extends Daosupport{

Corresponding class diagram
3. Realize the relationship
The realization relationship is actually the A class to implement the B interface, which is a special case of the dependency relationship

public interface PersonService {
public void delete(Interger id);
public class PersonServiceBean implements PersonService {
public void delete(Interger id){}

Class Diagram
4. Association
A reference relationship between objects, such as the relationship between the customer class and the order class. This relationship is usually expressed using the attributes of the class. The association can have direction, ie navigation. Generally, when not explaining, navigation is bidirectional, and there is no need to mark arrows on the line
Code example:

//One-way one-to-one relationship
public class Person {private IDCard card;}
public class IDCard{}
//Two-way one-to-one relationship
public class Person {private IDCard card;}
public class IDCard{private Person person}
  1. Aggregation relationship
    Aggregation refers to the relationship between the whole and part, and the whole and part can be separated. The aggregation relationship is a special case of association relationship, so it has associated navigation and multiplicity. For example, a computer is composed of a keyboard, a monitor, a mouse, etc.; the various components that make up the computer can be separated from the computer, which is indicated by a solid line with a hollow diamond:
    If we say that Mouse, Monitor and Computer are inseparable, then upgrade to combination relationship
  2. Combination relationship
    It is also the relationship between the whole and the part, but the whole and the part cannot be separated. It is a strong inclusion relationship. The combined class is responsible for the life cycle of the combined class. Attributes are also used to express the combination relationship, which is a kind of association relationship and a stronger relationship than the aggregation relationship.
    Third, the introduction of design patterns
    Design patterns are useful experiences that programmers have summed up in the face of similar software engineering design problems. Patterns are not codes, but general solutions to certain types of problems. Design patterns represent the best practice. These solutions are summarized by many software developers after a long period of trial and error. The essence of the design pattern improves the maintainability, versatility and scalability of the software, and reduces the complexity of the software.
    <> is a classic book, authored by Erich Gamma, Richard Helm, RalphJohnson and John Vlissides Design, which has a more in-depth introduction to design patterns
    There are three types of design patterns, a total of 23 types. 1) Created patterns:singleton patterns, abstract factory patterns, prototype patterns, builder patterns, and factory patterns. 2) Structural mode:adapter mode, bridge mode, decoration mode, combination mode, appearance mode, flyweight mode, proxy mode. 3) Behavioral mode:template method mode, command mode, visitor mode, iterator mode, observer mode, intermediary mode, memo mode, interpreter mode(Interpreter mode), state mode, strategy mode, chain of responsibility mode(Chain of responsibility model).