.Md principles of software design

1. Don’t Repeat Yourself (DRY)

• Public repeated code extraction method, function abstract template extraction operation and function minimization.
• If the project a lot of duplicate code, which means a lack of program design and abstract, such code is bloated, it is not simple, clear, easy to cause rewrite spread, and difficult to maintain.

2.Keep It Simple, Stupid (KISS)

• To simple things, such as binary computer, simple means to use, easy to understand, easy to maintain.
• what is simple? one is simple.
• Code written to profile, elegant, abstract reasonable and easy to understand.

3.Program to an interface, not an implementation

• Instead oriented programming interface for programming design implemented, the reference frame of the set of JAVA.
• Interface is the official language constraints, contract, foreign exchange

4.Command-Query Separation (CQS) - Command - Query the principle of separation

• Query interface does not change the state of the object, the command interface to change the state of the object
• Do not mix an interface colleagues queries and commands, which can result in an unstable state of the object state, so that the object in disarray
• A counter-example is that some people actually do get some of the mess in the operation of the method in the bean, hard to detect

5.You Ain’t Gonna Need It (YAGNI)

• Do not over-design, because you may not have to wait until the extension, the software has come to the end of the life cycle, or software has not been a commercial success, these are meaningless.
• To meet the immediate, appropriate future extension points can be expected to retain the (need for rational analysis)

6.Law ​​of Demeter (LOD) - Demeter

• Minimum know principle
• Do not have Feature Envy (Attachment Hunger), manage their like, do not too much attention to other people.

7. SOLID principles of object-oriented (SOLID (single function, the principle of opening and closing, Richter Alternatively, the interface isolation and dependency inversion))

1. Single Responsibility Principle (SRP) - a single responsibility principle
   a class only do one thing, you want to focus on instead of integration, counter-example is a tool Utils class has several unrelated operations

2. Open / Closed Principle (OCP) - opening and closing the principle
   of expansion is open and closed for modification
   can be completed with little changes when there are extension points, new features open for extension means that the program
   closed for modification means modification of the program does not affect the internal and external presentation, can be understood as oriented programming interface rather than to achieve
   should be written in a way plug-in modules and classes, but the classes do not overwrite increase class

3. Liskov substitution principle (LSP) - Richter substitution principle
   subclass must replace their base classes. Namely: sub-class should be replaced where any base class can appear, and later replaced after the code still work.

4. Interface Segregation Principle (ISP) - Interface Segregation Principle
   should feature a more complicated interface class and split into several independent interface class, so these easily isolated multiplexed interfaces, the interface type is not conducive to complex subclass writing, only a simple interface to facilitate the preparation of a subclass of class only
   positive examples Comparable, Serializable interfaces class has only one method.

5. Dependency Inversion Principle (DIP) - Dependency Inversion Principle
   level modules should not depend on low-level modules to achieve, but rather depends on the level of abstraction
   An example would be: go first to find someone to solve the problem of leadership, leadership arrangements that allow individuals to find men to solve the problem in the end . Your butt which is a member of the leadership rather than specific.

8. Common Closure Principle (CCP) - co-closed principle

• If the code is triggered changed, the value related to the classes in a package should be limited, should not be spread to other packages, modifications to converge.

9. High Cohesion & Low / Loose coupling & - high cohesion, low coupling

10. Convention over Configuration (CoC) - Convention over Configuration Principle

• The number of recognized and configuration information to use as an internal default rule
• Positive examples: Maven, Gradle, Spring Boot.

11. The normalized (to form a standard, specifications, processes, etc.)

12. classes, packages, which are not circular dependencies

13. The valuable thing to do, do not see themselves as the brute force of animals

references

• Some principles of software design
• What is the SOLID principles (Part 1)