Why study design patterns? Can be in the project design research and development is well-founded, skilled, boast basis
All design patterns can not be separated from the object-oriented foundation, object-oriented is the root, the design principle is the trunk, the design pattern is the branch tender leaves;
SOLID Principle -SRP single responsibility principle
Define that a class or module is responsible for only one responsibility;
How do you determine if the responsibilities of a class are simple enough?
- Too many lines of code, functions, or attributes in a class
- A class should have no more than 200 lines of code;
- The number of functions and attributes should not exceed 10.
- A class depends on too many other classes, or depends on too many other classes;
- Too many private methods;
- It can be difficult to name classes properly;
- A large number of methods in a class focus on a few properties of the class;
SOLID principle -OCP open and close principle
Definition, open for extension, closed for modification;
The most common ways to improve code extensibility are:
- polymorphism
- Dependency injection
- Programming based on interfaces rather than implementations
- Decorator mode
- The strategy pattern
- A template model
- Chain of Responsibility model
- The state pattern
SOLID principle -LSP Richter replacement principle
Define, the subclass object can replace the program in the parent class object of the task place, and ensure that the original program logic behavior unchanged and correctness is not destroyed;
It’s like polymorphism. What’s the difference?
From different perspectives, polymorphism is a feature of object-oriented programming, and it is a way of code implementation.
What code clearly violates the Richter substitution principle?
- A subclass violates what the parent class declares to do, such as having to change the way the parent class permits it
- A subclass violates the input, output, and exception conventions of its parent class
- Subclasses violate the task specific instructions listed in the parent staple
SOLID principle -LSP interface isolation principle
Define that the invocation of the interface this or the user should not be forced to rely on an interface that he does not need
What are interfaces?
- A collection of API interfaces designed to isolate unwanted parts of the microservice interface
- A single API interface or function that calls part of the function needs to be split into finer grained functions
- Object-oriented interface concept, interface design as far as possible single
SOLID principle -DIP dependence inversion principle
Inversion of control IOC
Inversion of control is not a specific implementation technique, but a relatively general design idea, which generally guides the framework level design. For example, springIOC container is the implementation of IOC design idea.
Here “control” refers to the control of the program flow, and “reverse” refers to the programmer control the execution of the program before the use of the framework, after the use of the framework to control the execution of the process to the framework; For example, the process of instantiating objects handed to the Spring IOC container does not perform manual control;
Dependency injection DI
Dependency injection (DI), as opposed to inversion of control, is a specific programming technique. In a nutshell, instead of creating a dependency object inside a class using new(), it is passed to the class using constructors, function parameters, etc.
Dependency injection framework. The Inversion of control of spring framework is mainly realized through dependency injection.
Dependency inversion principle
High-level modules do not depend on low-level modules. They all depend on the same abstraction. Abstraction does not depend on concrete implementation details.
DRY principle – Don’t duplicate code
Violating the DRY principle
- Implement logical repetition
- Functional semantic repetition
- Code execution repetition
The KISS Principle – Keep it simple
How to write the KISS principle code?
- Don’t use technology your partner doesn’t understand
- Don’t duplicate the wheel
- Don’t over-optimize
YAGIN principle – Don’t over design
It doesn’t make sense to over-design,
LOD principle – high cohesion and low coupling
Define that there should not be direct dependencies between classes that do not have dependencies; Between classes that have dependencies, try to rely on only necessary interfaces;
High cohesion, class itself design
Low coupling, design of dependencies between classes