Seven principles of object-oriented

I. Overview of object-oriented principles

The general context of the seven main principles:

　　

Two. The commonly used object-oriented design principles include 7, which are not isolated and interdependent and complementary to one another.

.

Three. The following detailed analysis:

(i) Single principle of responsibility (Responsibility Principle, SRP)

1, definition: An object should contain only a single responsibility, and the responsibility is completely encapsulated in a class

Or: In the case of a class, there should be only one cause for it to change.

2, Analysis: A class (or large to the module, small to the method) the more responsibility, it is more likely to be reused, and if a class assumed too much responsibility, it is equivalent to the responsibility of coupling together, when one of the responsibilities changes, may affect the operation of other functions. 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.

3. Example:

The example shows that the "login function" of a C/s system based on Java is implemented by the following login class (login):
A single responsibility principle is now used to reconstruct it.

(ii) Opening and closing principle (open-closed Principle, OCP)

1, definition: A software entity should be open to the extension, the modification is closed. 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.

2. Analysis: 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.

(iii) The principle of substitution on the Richter scale (Liskov Substitution Principle, LSP)

1, definition: If for each object of type S O1, there is an object of type T O2, so that all program P defined in T is changed to O2 for all objects O1, then the behavior of P is unchanged, so the type S is a subtype of type T

Or: All references to the base class (the parent class) must be able to use the object of its subclass transparently.

2. Analysis: The principle of substitution of the Richter scale 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 principle of substitution of the Richter scale can be expressed as follows: if the base class object can be used in software, its subclass object must be used. 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 principle of substitution of the Richter scale 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, while at run time the subclass type is determined, and the child class object is substituted for the parent class object.

(iv) reliance on reversal principle (dependence inversion Principle, DIP)

1, definition: High-level modules should not rely on low-layer modules, they should be dependent on abstraction. Abstractions should not be dependent on detail, and details should be dependent on abstraction

Or: To program for the interface, do not program for implementation. (Program to a interface, not a implementation.)

2, Analysis: The principle of dependence reversal is Robert C. Martin in 1996 for the "C + + Reporter" column Engineering notebook third, and later added to his 2002 edition of the classic "Agile software Development, principles, Patterns, and practices.

Simply put, the dependency reversal principle means that the code relies on abstract classes rather than on specific classes, programming to 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.

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.

(v) Interface Isolation principle (Interface segregation Principle, ISP)

1, definition: The client should not rely on those interfaces it does not need to note that the interface in the definition refers to the defined method.

Or: 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.

2, Analysis: the principle of interface isolation refers to the use of multiple specialized interfaces, without using 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.

When you split an interface using the interface isolation principle, you must first meet a single principle of responsibility, define a set of related operations in an interface, and, with high cohesion, the fewer methods in the interface are as good as possible. Can be used in the design of the system in a customized way, that is, for different clients to provide a wide range of interfaces, only the user needs to provide the behavior, and hide the user does not need the behavior.

(vi) Synthetic multiplexing principles (Composite reuse Principle, CRP), also known as combinatorial/aggregation multiplexing principles (composition/aggregate reuse Principle, CARP)

1, definition: Try to use the object combination, rather than inheritance to achieve the purpose of reuse. (Favor composition of objects over inheritance as a reuse mechanism.)

2. Analysis: The principle of synthetic reuse refers to the use of 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.

(vii) Dimitri (Law of Demeter, LoD) also known as the least-knowledge principle (Least knowledge Principle, LKP)

1. Definition:

(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.

2, Analysis: Dimitri Law from the 1987 fall of the United States Northeastern University (Northeastern University) a research project called "Demeter". 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.

Seven principles of object-oriented