An overview of object-oriented design principles of "OOAD"

• The maintainability and reusability of software
  
  

Robert C.martin, a well-known software guru, believes that a low-maintainability (maintainability) software design is typically caused by the following 4 reasons:
? too stiff (rigidity)
? Too fragile (fragility)
Low reuse rate (immobility)
? High viscosity (Viscosity)

The software engineering and modeling guru Peter Coad believes that a good system design should have the following three properties:
? Scalability (Extensibility)
? Flexibility (flexibility)
? Pluggable (Pluggability)

Software reuse (reuse) or reuse has many advantages, such as improving software development efficiency, improving software quality, saving development costs, and the appropriate reuse can also improve the maintainability of the system.
The goal of object-oriented design multiplexing is to enable multiplexing that supports maintainability.
In object-oriented design, maintainability reuse is based on the principle of object-oriented design, which is the principle of reuse, which can effectively improve the reusability of the system and improve the maintainability of the system.

The object-oriented design principle and design pattern are also the compass to reconstruct the system rationally, and the reconstruction (refactoring) is to improve the quality and performance of the software by adjusting the program code without changing the existing functions of the software, and make the design pattern and structure of the program more reasonable, and improve the expansibility and maintainability of the software.

• Introduction to Object-oriented design principles

Commonly used object-oriented design principles include 7, these principles are not isolated, they depend on each other and complement each other.

• Single principle of responsibility

Definition of a single responsibility principle
Single responsibility principle (SRP), in the case of a class, there should be only one cause for it to change.
Each class should has one and only one reason to the change.

If a class takes on too much responsibility, it is tantamount to coupling these responsibilities,
A change in one's responsibilities may weaken or inhibit the ability of this class to perform other duties.
This coupling leads to fragile designs that can be subjected to unexpected damage when the changes occur.

The single Responsibility Principle, SRP, is defined as follows:
An object should contain only a single responsibility, and the responsibility is fully encapsulated in a class.
The English definition is:
Every object should has a single responsibility, and that responsibility should is entirely encapsulated by the class.
Another way to define this is as follows:
As far as a class is concerned, there should be only one cause for it to change.
The English definition is:
There should never is more than one reason for a class-to-change.

analysis of single duty principle
The more responsibilities a class (or large to a module, small to a method) assumes, the less likely it is to be reused, and if a class takes on too much responsibility, it is tantamount to coupling those responsibilities together, and when one of the responsibilities changes, it may affect the operation of other responsibilities.
The responsibilities of the class include two aspects: data responsibility and behavior responsibility, data responsibility is embodied by its attribute, and behavior responsibility is embodied by its method.
Single responsibility principle is to achieve high cohesion, low-coupling guidelines, in many code refactoring techniques can find its existence, it is the simplest but the most difficult to apply the principle, requires designers to discover the different responsibilities of the class and separate it, and the discovery of multiple responsibilities of the class requires designers have strong analytical design capabilities and related refactoring experience.

Do you have too much responsibility for your phone?
Eat Western food: knife and Fork, Division of labor is very clear, knife is cutting food, fork is fixed food or mobile food;

• Opening and closing principle

Definition of opening and closing principle
For the extension is open (open for extension),
Closed for changes (Closed for modification)

The opening and closing principle (open-closed Principle, OCP) is defined as follows:
A software entity should be open to extensions and closed for modifications. In other words, when designing a module, it should be allowed to be extended without modification, that is, to change the behavior of the module without modifying the source code.
The English definition is:
Software entities should is open for extension and closed for modification.

More popular, that is, we have developed a software, it should be able to expand the function (open), and in these extensions, the original program does not need to modify (off)!

Bertrand Meyer is a software engineering professor at the ETH Zurich and is also the chief architect of Eiffel Software, who leads and designs eiffelstudio environments and a large number of libraries. He is the author of some of the best sellers, including the object-oriented software construction (Prentice Hall), which won the Jolt Award. He also obtained the ACM Software System Award and the Dahl-nygaard Award for his work on object technology and Eiffel, and obtained St. Honorary doctorate degree from Petersburg State Technical University. His research interests relate to object-oriented technology, programming languages, software validation (including testing, concurrency, and canonical methods). He is also an active consultant and lecturer.

analysis of opening and closing principle
The opening and closing principle was proposed by Bertrand Meyer in 1988, which is one of the most important principles in object-oriented design.
In the definition of open and closed principle, a software entity can refer to a software module, a local structure consisting of multiple classes, or a separate class.
Abstraction is the key to the open and closed principle.
The open and closed principle can also be described by a more specific "principle of variability encapsulation", which requires the variable packaging principle (Principle of encapsulation of Variation, EVP) to find and encapsulate the variables of the system.

• Principle of substitution on the Richter scale

The Richter substitution principle defines the
Richter substitution principle (Liskov Substitution Principle, LSP), which is defined in two ways, the first of which is relatively strict and is defined as follows:
If each object of type S is O1, there is an object O2 of type T, so that all program P defined in T is replaced with O2 for all objects O1, and the behavior of the program P does not change, then the type S is a subtype of type T. The
is defined in the English language as:
If for each object O1 of type S There are an object O2 of type T such so for all programs P defined in ter Ms of T, the behavior of P is unchanged when O1 are substituted for O2 and S is a subtype of T.
the second easier to understand definition is as follows:
All primers An object of its subclass must be used transparently where the base class (parent) is used. The
is defined in the English language as:
Functions, pointers, or references to base classes must being able to use objects of derived classes WI Thout knowing it.
Analysis of the substitution principle of the Richter scale

The

Richter substitution principle was presented in 1994 by the 2008 Turing Award winner, the first woman of computer science in the United States, Professor Barbara Liskov of MIT, and Professor Jeannette Wing of Carnegie Mellon University. The original text is as follows: Let Q (x) is a property provable about objects X of type T. then Q (y) should are true for objects Y of the type S where S is a subtype of T.
The principle of substitution of the Richter scale can be expressed in layman's terms: If you can use a base class object in the software, you must be able to use its subclass object 。 Replace the base class with its subclasses, the program will not produce any errors and exceptions, and conversely, if a software entity uses a subclass, then it is not necessarily able to use the base class. The
Richter substitution principle is one of the important ways to realize the open and closed principle, because the subclass object can be used wherever the base class object is used, so as far as possible the base class type is used in the program to define the object, and at run time the subclass type is determined, and the subclass object is substituted for the parent class object.

Barbara Liskov (Barbara Liskov), American computer scientist, 2008 Turing Award winner, 2004 John von Neumann prize winner, American Academy of Engineering, Fellow of the American Academy of Arts and Sciences, American Computer Association. He is a professor at MIT's Department of Electrical and Computer science. She is the first female doctor of computer science in the United States.
Zhou Yijien (Jeannette M. Wing), American computer scientist, professor of the University of Carnegie Mellon, Assistant secretary of the National Nature Fund's Department of Computational and Information Science Engineering, ACM and IEEE.
Barbara liskov,2008 of the annual American Computer Society (ACM) Turing Award (Turing Award), the first woman to obtain a PhD in computer Science (Stanford University, 1968), its innovative research has brought great changes to the field of computer programming. It is presented even earlier than the OCP. Unfortunately, due to the different understanding of this principle, after many translations, the LSP has become one of the most controversial topics in ood design principles. in fact, at the OOPSLA conference in 1987, Ms. Liskov of the MIT Computer Science Lab published the classic article Data abstraction and Hierarchy, The Liskov substitution principle (the Liskov Substitution Principle), named after her name, is proposed, which is referred to as LSP. This principle explains when to use inheritance, when to use it, and why.

The Richter replacement method contains four layers of meaning:
Subclasses must fully implement the method of the parent class;
Subclasses can have their own personalities;
Input parameters can be magnified when overriding or implementing a method of the parent class;
The method of overriding or implementing the parent class is that the output can be scaled down.

• Dependency reversal principle

dependency reversal Principle Definition
The dependency reversal principle (dependence inversion Principle, DIP) is defined as follows:
High-level modules should not rely on low-layer modules, they should all rely on abstraction. Abstractions should not be dependent on detail, and detail should be dependent on abstraction.
The English definition is:
The modules should not depend upon low level modules, both should depend upon abstractions. Abstractions should not depend upon details, details should depend upon abstractions.
Another expression is:
to program for the interface, do not program for implementation.
The English definition is:
Program to a interface, not an implementation.
analysis of dependency reversal principle
The dependency reversal principle was Robert C. Martin's third engineering notebook in 1996 for the C + + Reporter column, which he later joined in his 2002 classic, Agile software Development, principles, Patterns, and practices.
In simple terms,dependency reversal principle means that code relies on abstract classes rather than on specific classes, programming for interfaces or abstract classes, rather than specific classes.
The key to realize the open and close principle is abstraction, and from abstract to materialize realization, if the principle of opening up is object-oriented design, then the dependency reversal principle is the main means of object-oriented design.
One of the common implementations of the dependency reversal principle is to use abstract classes in your code and place specific classes in the configuration file.
"Put abstractions into code, put details into metadata"
Put abstractions in Code, Details in Metadata
("Programmer's Path: from the handyman to the expert" (the Pragmatic Programmer:from journeyman to master)

Coupling between classes
? 0 Coupling relationship
? Specific coupling relationship
? Abstract coupling relationship
The dependency reversal principle requires the client to rely on abstract coupling, and abstract coupling is the key to the dependency reversal principle.

Dependency Injection
Construct injection (Constructor injection): Injects an instance variable through a constructor.
Set value injection (setter injection): injects instance variables through setter methods.
Interface Injection (Interface injection): Injects an instance variable through an interface method.

• Interface Isolation principle

Interface Isolation principle Definition
The interface isolation principle (Interface segregation Principle, ISP) is defined as follows:
The client should not rely on interfaces that it does not need.
The English definition is:
Clients should not being forced to depend upon interfaces, that they does not use.
Note that the interface in the definition refers to the method that is defined.
Another way to define this is as follows:
Once an interface is too large, it needs to be split into smaller interfaces, and clients using that interface need only know the methods associated with them.
The English definition is:
Once an interface have gotten too ' fat ' it needs to is split into smaller and more specific interfaces so, any clients Of the interface would only know about the methods, that pertain to them.
Analysis of the principle of interface isolation
Robert C. Martin introduced in 1996
The principle of interface isolation refers to the use of multiple specialized interfaces rather than a single total interface. Each interface should assume a relatively independent role, not a lot, do not do the things that should be done to do.
(1) An interface represents only one role, and each role has its own specific interface, and this principle can be called the "role isolation principle".
(2) The interface only provides the behavior that the client needs, that is, the required method, the client does not need to hide the behavior, should provide the client with the smallest possible separate interface, rather than provide a large total interface.

• The principle of synthetic multiplexing

Definition of synthetic reuse principle
The synthetic multiplexing principle (Composite reuse Principle, CRP) is also known as the combinatorial/aggregation multiplexing principle (composition/aggregate reuse Principle, CARP), which is defined as follows:
Try to use object combinations instead of inheritance to achieve reuse.
The English definition is:
Favor composition of objects over inheritance as a reuse mechanism.
Analysis of the principle of synthetic multiplexing
The principle of synthetic reuse is to use some existing objects in a new object through association relationships (including combinatorial relationships and aggregation relationships) to make them part of new objects; The new object is used to re-use its existing functions by delegating methods that call existing objects. in short: Use the combination/aggregation relationship as much as possible, with less inheritance.
In object-oriented design, there are two basic methods for reusing existing designs and implementations in different environments, that is, by combining/aggregating relationships or through inheritance.
Inheritance reuse: Simple to implement and easy to scale. The encapsulation of the system is compromised; the implementations inherited from the base class are static, impossible to change at run time, not flexible enough, and can only be used in a limited environment. ("White box" multiplexing)
Combination/Aggregation multiplexing: a relatively low degree of coupling, optionally invoking the operation of a member object, which can be performed dynamically at run time. ("black box" multiplexing)

Combination/aggregation can make the system more flexible, the coupling between classes and classes is reduced, the change of one class has a relatively small impact on other classes, so it is generally preferred to use combination/aggregation to achieve reuse, followed by inheritance, in the use of inheritance, need to strictly follow the Richter substitution principle, effective use of inheritance will help to understand the problem , reducing complexity, while abusing inheritance increases the difficulty of building and maintaining the system and the complexity of the system, so you need to use inheritance reuse sparingly.

• Dimitri Law

Dimitri Rule definition
A software entity should interact with as few interactions as possible with other entities
The Dimitri rule (Law of Demeter, LoD), also known as the least-knowledge principle (Least knowledge Principle, LKP), has several defining methods, several of which are typically defined as follows:
(1) Do not talk to "strangers". The English definition is: Don ' t talk to strangers.
(2) communicate only with your direct friends. The English definition is: talk only to your immediate friends.
(3) Each software unit has only the least knowledge of the other units, and is limited to the software units closely related to the unit. The English definition is as follows: Each unit should has only limited knowledge on other units:only units "closely" related to the current unit.
Analysis of Dimitri Law
The Dimitri Law came from a research project called "Demeter" at Northeastern University (Northeastern University) in the fall of 1987.
To put it simply, the Dimitri rule means that a software entity should interact with as few entities as possible. thus, when a module is modified, it will minimize the impact of the other modules, the extension will be relatively easy, this is the software entity communication between the restrictions, it requires limiting the width and depth of communication between software entities.

In the Dimitri law, for an object, its friends include the following categories:
(1) The current object itself (this);
(2) An object that is passed into the current object method in the form of a parameter;
(3) The member object of the current object;
(4) If the member object of the current object is a collection, then the elements in the collection are also friends;
(5) The object created by the current object.
Any object, if one of the above conditions is met, is the "friend" of the current object, or "stranger".

Dimitri Law can be divided into narrow law and generalized law. In the narrow Dimitri law, if two classes do not have to communicate with each other directly, then these two classes should not have direct interaction, if one of the classes needs to invoke a method of another class, you can forward the call through a third party.

narrow Dimitri Law : can reduce the coupling between classes, but will add a large number of small methods in the system and scattered in the system, it can make a system of local design simplification, because each part will not and long-distance objects have a direct association, However, the communication efficiency between different modules of the system can be reduced, which makes the system not easy to coordinate with each other.
Generalized Dimitri Law : refers to the control of information flow, flow direction and the influence of information, mainly on the control of information hiding. The concealment of information can decouple the subsystems, allowing them to be developed, optimized, used and modified independently, while facilitating the reuse of the software, since each module does not depend on other modules, so each module can be used independently of other places. The larger the size of a system, the more important it is to conceal information, and the greater the importance of information hiding.

The main purpose of the Dimitri Law is to control the overload of information :
In the division of classes, we should try to create loosely-coupled classes, the lower the coupling between classes, the more conducive to reuse, a loosely coupled class once modified, will not cause too much impact on the associated classes;
In the structure design of the class, each class should minimize its member variables and the access rights of member functions;
In the design of a class, whenever possible, a type should be designed as an immutable class;
On references to other classes, one object's references to other objects should be minimized.

Example of Dimitri Law
Example description
The call relationship between a system interface class (such as Form1, FORM2, etc.) and data access classes (such as DAO1, DAO2, and so on) is more complex:

An overview of object-oriented design principles of "OOAD"