Ood Principles
Object-oriented design principle summary
The Principles of Class Design:
SRP (Single Responsibility Principle) Single Responsibilities Principle: A class should have only one responsibility. The so-called responsibility is to guide the cause of this class. If a class has more than one duty, there will be several different reasons to cause this type of change, in fact, it is coupled to each other, not related responsibilities. The cohesiveness of this class will be reduced.
Open - Closed Principles: Software entities (class, modules, functions, etc.) should be expandable, but cannot be modified.
The modules that follow the OCP principles have two main features. They are:
1. "Open for Extension"
This means that the behavior of the module can be expanded. When the demand change of the application is, we can wake up extensions in the module to make it satisfied with new behaviors. In other words, we can change the functionality of the module.
2. "CLOSE for MODIFICATION".
When the module is expanded, the source code or binary code of the module is not necessary. Module's binary code executable, no matter how you can connect, DLL or Java .jar files do not need to be changed.
The mechanism behind OCP is mainly abstraction and polymorphism.
LSP (Lisk Substitution Princi) Lisk (Subtype) must be able to replace their base type (Base Type). If the object O1 of each type S is the object O2 O2, the program P behavior is not changed in all program p written for T, after the O1 is replaced, the program P behavior is constant, then S is the subtype of t .
DIP (Dependency-Inversion Principles) Relying on Invert Principles: 1. High-level modules should not depend on low-level modules. Both should depend on abstraction. 2. Abstract should not depend on the details. Details should depend on abstraction.
Using DIP:
Any variable should not hold a pointer or reference to a specific class.
Any class should not be derived from the specific class.
Any method should not write the already implemented method in its base class.
ISP (Interface SegRegation Principles) Interface Isolation Principle: Do not force customers to rely on how they don't need. The interface belongs to the customer and does not belong to the class hierarchy.
These client programs are facing changes due to changes in these unused methods depending on the methods they do not use. This is inadvertently leading to coupling between all customer programs. In other words, if a client depends on a class that contains the way it is not used, other clients should use this method, then this client will affect this client when other customers require this class. We want to avoid this coupling as much as possible, so we want to separate the interface.
The Principles of Package Cohesion:
REP (Reuse Release Equivalence Princi) Reuse publishing equivalence Principle: Re-use granularity is the issuance of particle size.
A Granule of Reuse is as large as the Granule of Reuse. Everything we reuse must be published and tracked at the same time. If the software in a package is used to reuse, then it can no longer contain software not designed to reuse purposes. Software in a package is either reusable or not reuse.
CRP (Common Reuse Princi) co-reused principles:
All classes in a package should be commonly reused. If you reuse a class in the package, you have to reusable all classes in the package. Classes that do not practice closely to each other should not be placed in the same package.
CCP (Common Closure Princi) co-closed principles: All classes in the package should be closed together for changes in the same type of nature. A variation will have an impact on a package, which will have an impact on all classes in the package, and no impact on other packets. If there is a very tight binding relationship between the two classes, whether it is physically or conceptually, they will always change together, so they should belong to the same package. This will reduce the workload of software, re-authentication, and re-release the workload.
The Principles of Package Coupling:
ADP (Acyclic Dependencies Princi) ringless dependence: The ring is not allowed in the redeemed relationship diagram of the package. There is a loop, in fact, the brackets in the ring become a big bag. This loop makes the isolation of the module very difficult; unit testing and release become very difficult and easy to errors; the construction of the package is not appropriate.
Release the dependency ring: Use the DIP principle, depend on abstraction; or recreate the package you want to rely.
SDP (Stable Dependencies Princi) Stable Dependency Principle: During the stable direction.
For any package, if it is variable, it should not let a difficult package depend on it! Otherwise, the variable package will also be difficult to change.
Calculate the position stability of the package:
(CA) AffERENT Coupling: Refers to the number of classes of the package and depends on the class of classes within the package.
(CE) EFFERENT Coupling: Refers to the number of classes in the package and depends on the class outside the package.
(Instability i)
I = CE / (CA CE)
SDP specifies that the I measure value of a packet should be greater than the measure value of the I it depends on (that is, the I metric should be reducing the direction of dependent).
SAP (Stable Abstractions Princi) Stable Abstract Principle: The abstraction of the package should be consistent with its stability. This principle links the stability and abstraction of the package. It stipulates that a stable package should be abstract, so its stability makes it flexibly. On the other hand, an unstable package should be concrete because its instability makes it easy to modify the specific code in its inside.
Abstract sector:
A is a metric standard for measuring the degree of abstraction. Its value is the number of abstract classes in the package and the ratio of the number of all classes.
A = NC / NA
NC: The total number of classes in the package.
NA: The number of abstract classes in the package. Keep in mind that an abstract class is a class with at least one pure interface, and it cannot be instantial.
A: Abstract
Draw a coordinate map with stability (I) as horizontal axis, abstract (a) is the vertical axis.
The upper left corner (0, 1) represents the most stable and most abstract, the lower right corner (1, 0) indicates the most unstable, most specific.
The main sequance: is a connection between two endpoints. A i = 1
The Zone of Uselessness area is useless, there is a maximum abstraction, but there is no dependency (unstable).
The zone of pain is a painful zone, and there is little abstraction in the section but too stable.
The best position of the package is on the two endpoints of the main sequence, but do it in the main sequence or in the vicinity of the main sequence.
Distance to the main sequence: d = | a i-1 | / √2 (root number 2)
The smaller the value of D, the better, for all the packs that are not in the vicinity of the D value, are reviewed and adjusted.
