The general rule of design not only describes how to design a class, but also goes up to the design of the entire component and down to the design of a single method in the class.
Single Responsibility Principle-SRP For a class, there should be only one reason for its changes.
Principles The simplest, simplest, and most effective thing is the easiest to control
Class responsibilities are simple and centralized, so that the same responsibilities are not distributed to different classes, so that one class can take too many responsibilities.
Reduces coupling between classes
When the demand changes, only one place is modified.
Components
Do one thing in every component
Granularity of components
Release cost
Reusable costs
Method
Avoid overhead writing
Extract Method
Reconstruction
Move field/move class
Extract Method/extract class is the simplest and most difficult to master principle.
Instance analysis
Olite
OCP
Software entities (classes, modules, and functions) should be extensible, but cannot be modified.
Principles
It is open to expansion. When the demand changes, we can expand the module to provide new functions.
The changes are closed, and you do not need to change the original Code
Abstract is more active than detail in the face of abstraction than detail.
Rigid Design-if Program One change produces a chain reaction.
Method
Conditional case if/else statement
Reconstruction
Replace type code with Class
Replace type code with State/Strategy
Replace conditional with Polymorphism
Instance
Plug-ins
Data-driven ordercycle
Liskov replacement principle LSP
The child type must be able to replace its base type
Principles
Mainly for the design principles of Inheritance
The behavior functions of all derived classes must be consistent with those expected by the client program for their base classes.
The derived class must meet the conventions of the base class and client program.
The IS-A is about the behavior, depending on the call method of the Client Program
Reconstruction
Extract supper class
Instance
Rectangle and square
Dependency inversion principle dip
A: The high-level module should not depend on the underlying module, both of which should depend on abstraction.
B: Abstraction should not depend on details, but on abstraction.
Principles
How to invert
The high-level dependency on the underlying layer makes reuse difficult, and the most frequently used is the framework and various independent functional components.
The top layer depends on the bottom layer, and the underlying changes are directly fed back to the top layer to form interface-oriented programming for dependency transmission.
Instance
IOC Mode
Domainobject/domianobjectdataservice
Reference
Agile Software development principles, models and practices http://microhelper.blogdriver.com/microhelper/432102.html
