Six Design Principles

1. Single Responsibility Principle (SRP: single Resposibility Principle)

"Responsibility" or "cause of change" is used to determine whether an interface or class is well designed. However, "responsibility" and "cause of change" are both non-measurable and vary with projects.

Benefits:

• Class complexity is reduced, and responsibilities are clearly defined
  

• Improved readability
  

• Maintainability Improvement
  

• Reduced risks caused by changes

For example, separate attributes and behaviors.

I am simple, so I am happy.

Best Practice: The interface must have a single responsibility, and the class design should be changed for only one reason.

2. Lean replacement principle (LSP: liskov subsititution principle)

Inheritance advantages: code sharing improves code reusability, similar to parent class and different from parent class. This improves code scalability and the openness of projects or products.

Disadvantages of inheritance: intrusion, reduced flexibility, and enhanced Coupling

How can we develop strengths and circumvent weaknesses? LSP defines a specification for good inheritance.

Test criteria: as long as the parent class can appear, no exceptions or errors will occur after the child class is replaced. The description complies with LSP specifications.

Layer-4 meaning:

• Subclass must fully implement the parent class method.

1. During system design, an interface or abstract class is often defined. Calling a class directly passes in an interface or abstract class.
   

2. When calling other classes in the class, you must use the parent class or interface. Otherwise, the class design violates the LSP principle.
   

3. If the subclass cannot fully implement the parent class method, or some methods of the parent class have been malformed in the subclass, we recommend that you disconnect the Parent and Child inheritance units, inheritance is replaced by dependency, aggregation, and combination.
   

• Child classes can have their own personalities.
  

• When overwriting or implementing the parent class method, the input parameter can be enlarged.

• Output results can be reduced when override or parent classes are implemented.

LSP is used to enhance program robustness and maintain excellent compatibility with version upgrades.

3. Dependency inversion principle (DIP: dependence inversion principle)

• Dependencies between modules are abstracted to prevent direct dependencies between classes. The dependencies are generated by interfaces or abstract classes.
  

• The interface or abstract class does not depend on the Implementation class.
  

• Implement class dependency interface or abstract class
  

One sentence: interface-Oriented Programming

Objective of Using Dip:

• Reduce inter-class coupling: Check for loose coupling when a change occurs.

• Provides System Stability: The design with high stability can still be "I am not sure" when the surrounding environment changes frequently.

• Reduce the risks caused by parallel development: otherwise it is difficult to achieve parallel development. There is a dependency between the two classes, as long as the interface or abstract class between the two is developed independently. Unit Tests Between projects can also be run independently. TDD (test-driven development, test-driven development) mode is the most advanced application of LSP. The jmock tool virtualizes an object based on the abstraction for testing. TDD: First, write the unit test class. It is especially suitable for R & D projects or project members with low level of organization.

• Improve code readability and maintainability.
  

Three methods of dependency writing:

• Constructor transmits dependent objects (constructor injection)

• Setter method to pass dependency object (setter injection)

• Interface declaration dependent object (interface injection)

Best practices:

• Every class has an interface, an abstract class, or an abstract class or an interface.
  

• The surface type of the variable should be an interface or abstract class.

• No class should be derived from a specific class

• Try not to override the method of the base class

• Use with LSP principles

Common rules: interfaces define public attributes and methods, and declare dependencies with other objects; abstract classes are responsible for implementing public constructor; implementation classes accurately implement business logic, at the same time, the parent class is refined as appropriate.

4. Interface segregation principle)

Definition: create a single interface. Do not create a bloated interface. That is, the interface should be as detailed as possible, and the methods in the interface should be as few as possible.

Different from the single responsibility principle. One is to divide responsibilities from the business perspective; the other is to avoid too many methods in it; otherwise, permission control is inconvenient, that is, Methods unrelated to callers are exposed.

Layer 4 meaning:

• The interface should be as small as possible: When splitting an interface based on the Interface isolation principle, the single responsibility principle must be met first.

• High Cohesion for interfaces [High Cohesion: Improves the processing capabilities of interfaces, classes, and modules and reduces external interactions]: public methods must be published as few as possible in interfaces, and interfaces are external commitments, the less the commitment, the more favorable the system development, the less the risk of changes, but also helps reduce costs.

• Custom Service: when designing a system, you must consider using custom services for interfaces between systems or between modules. Only the methods required by visitors are provided.

• The interface design is limited: the smaller the granularity of the interface design, the more flexible the system, the more complex the structure, the more difficult the development, the lower the maintainability. Grasp the "degree".

Best practices:

• An interface serves only one submodule or business logic;

• Public method in the Service Logic compression Interface

• Modify contaminated interfaces as much as possible. If the risk of changes is high, use the adapter mode for conversion.

• Practice, experience, and comprehension.

5. dummit principle (SLS, law of Demeter)/least knowledge principle (LKP, least knowledge principle)

An object should have a minimum understanding of other objects. A class should know the least about the classes that need to be coupled or called. The internal complexity of the classes to be coupled or called is related to me, I only know the public method you provided, and I don't care about anything else.

High cohesion in the class, low coupling between classes.

We recommend that you do not disclose too many public methods and non-static public variables to the public, and use private, package-private, and protected access permissions as much as possible.

Methods can be placed in this class, and there is no error in other classes. How can this problem be measured?Principle: if a method is put in this class, there is no inter-class relationship, and there is no negative impact on this class, it will be placed in this class.

6. open closed Principle)

Definition: A software entity, such as a class, module, or function, should be open to extensions and closed to modifications.

Understanding: A software entity should implement changes through extensions, rather than modifying existing code.

The principle of opening and closing is the most basic principle. The preceding five principles are the specific form of the principle. The first five principles are the tools and methods to guide the design, and the open and closed principles are the spiritual leaders.

How to use:

• Abstract constraints: abstraction is a general description of a group of things. Without specific implementation, it indicates that it can have a lot of possibilities and change with the changes of requirements.

• Limits the boundaries of an extension by using an interface or abstract class. Public methods that do not exist in an interface or abstract class are not allowed.

• Use interfaces or abstract classes as much as possible for parameter types and referenced objects, rather than implementing classes

• The abstraction layer should be as stable as possible and cannot be modified once determined.

• Metadata control module behavior: use configuration parameters whenever possible to control program behavior and reduce repeated development. For example

• Struts interceptor

• Spring IoC

• Develop Project Charter: Better than Configuration

Six Design Principles