There are also design patterns for adding, deleting, modifying, and querying-Dependency inversion principle

An example of adding, deleting, modifying, and querying: interface-Oriented Programming and dependency inversion principle Dependency inversion principle Introduction

The dependency inversion principle consists of two parts:

• . High-level modules should not depend on low-level modules. They should all rely on abstraction.
• Abstraction should not depend on specific implementations, but on abstraction. Example

  Now we have the following scenarios and requirements:
  The boss asked to design the task module, including publishing and recalling the task.
  
  Assuming that this requirement is only provided for a few hours, it is definitely too late to design it.
  The control layer for defining the recall interface is as follows:

@ Requestmapping ('cancel') @ responsebodypublic string canceltask (Task task) {// todo calls the Service's recall interface return "{'status': 'success '}";}

Important

At this time, the cancel interface of the service layer has not been written, because a task object is created when springmvc data is automatically bound. Naturally, the following interface is defined.

Public void cancel (Task task) throws serviceexception {};
Instead
Public void cancel (string taskid) throws serviceexception {}

Because I have a ready-made task object on hand, the first parameter I want to transmit is the task. The two differences are also very simple. The second one needs to be added to the Code.

Task task = This. findonebyid (taskid); // because the code is at the service layer, the findonebyid interface is generally available.

Well, because I already have tasks, I will naturally give two hints at this time:

• If the parameter I accept is taskid, I need to perform io with the database. If the caller has already performed Io once, isn't this unnecessary?
• The caller should be able to ensure that the data transmitted to the task is correct.

The error dependency has already occurred.
1. When defining an interface, we assume that the input parameters are the latest in the database, but this cannot be guaranteed. What is the role of revoking an interface? Is to change the task status fromProcessingMediumPending
2. Both the top and bottom layers depend on the implementation, because it is based onI already have a task object, so I don't want to consume performance any more.This section of the existing code logic defines the interface
Which of the following statements is true?
When defining a recall interface, you should discard the existing code and think about the responsibility of this interface: change the status and perform other operations.
1. You only need an ID to change the status. Other operations do not depend on passing parameters at the upper level.
2. When defining an interface, you should consider its responsibilities to define abstraction, and code implementation should abide by the functions to be implemented by this abstraction.

This is

• . High-level modules should not depend on low-level modules. They should all rely on abstraction.
• Abstraction should not depend on specific implementations, but on abstraction.
  Also interface-Oriented Programming

The above is an alternative solution found during self-development. The general solution is as follows:

The principle of dependency inversion actually refers to the calling through interfaces instead of implementing classes when calling the lower layer. Once the lower layer changes significantly, the upper layer will not fluctuate much.

Assume that the following scenarios are met:

Students

Public class student {public void read (honglou) {// traverse each row for (line: honglou. getlines) {// a line of James reads this. see (line) ;}} public class honglou {public list <line> getlines (){};}

At this time, James depends on a specific class of honglou. Once Xiaoming wants to read other books (using other implementations), it cannot be implemented.

If an iBook class is defined as the base class at this time:

Public class student {public void read (iBook book) {// traverse each row for (line: Book. getlines) {// a line of James reads this. see (line) ;}} public interface iBook {public list <line> getlines ();}

In this way, Once James wants to read other books, he can modify the specific derived object when passing parameters.
This principle is a commonly used principle in design patterns. Many Design Patterns define some Derived classes to implement interfaces. For example, the abstract factory class defines a set of interfaces and is implemented by a specific factory class. When you need to switch other modes, you can switch the implementation class.
Policy mode: defines an algorithm interface that requires them to switch at any time. Different algorithm derived classes implement the same interface. The algorithm calling class depends on the Interface rather than the specific policy class.

There are also design patterns for adding, deleting, modifying, and querying-Dependency inversion principle