A brief introduction to the concepts and design principles of OO in Java (Collection)

The following editor will bring you a brief discussion on the concept of OO in Java and design principles (must read). The editor thinks it’s pretty good, so I’ll share it with you now and give it as a reference. Let’s follow the editor and take a look.

1. The design basis of OO (Object-oriented)

Object-oriented (OO): It is based on the object concept, centered on the object, and based on classes and inheritance is a construction mechanism, making full use of interfaces and polymorphism to provide flexibility to recognize, understand, characterize the objective world and design and build corresponding software systems. Object-oriented features: Although various object-oriented programming languages ​​are different from each other, they can all be seen to support the basic features of object-oriented programming, namely "abstraction, encapsulation, inheritance, Polymorphism”:

–Abstract,

Ignore the details–Encapsulation,
Hide internal implementation – Inheritance,
Reuse existing code– Polymorphism,
Rewrite objectBehaviorObject-orientedDesign pattern: It is "good object-oriented design". The so-called "good object-oriented design" is those designs that can meet the requirements of "responding to changes and improving reuse". Object-oriented design patterns describe software design, so it is independent of programming languages, but the final implementation of object-oriented design patterns must still be expressed using object-oriented programming languages. Object-oriented design patterns are not like algorithmic techniques that can be copied and used. It is an empirical understanding based on a proficient and in-depth understanding of "object-oriented".

The above gives a broad description of the concepts and relationships between object-oriented and design patterns. When we design, we fully understand and use the four basic characteristics of OO to carry out the design. Therefore, everyone must be familiar with and master the object-oriented technology before designing. I will not introduce it in detail here, but for Design patterns provide us with a reference model when designing, and the prerequisite for mastering object-oriented design patterns is to first master "object-oriented" technology.

two. The design goals of OO (object-oriented)

※Extensibility:

With new requirements, new performance can be easily added It will not affect the existing performance or bring new defects into the system. ※Modifiability Flexibility:

When the code of part of the system needs to be modified, it will not destroy the existing structure of the system, nor will it affect otherspart. ※Replaceability Pluggability:

Some codes in the system can be replaced with other classes with the same interface without affecting the system. three. The five major principles of OO design and their relationships

3.1 Summary of OO design principles

※Single Responsibility Principle:

As far as a class is concerned, there should be only one reason for its change. Singleness is good design for a class. Mixed and unclear responsibilities will make the code look particularly awkward, affecting the whole body, losing aesthetics and inevitably leading to the risk of ugly system errors. ※Open and closed principle:

means that software entities (classes, modules, functions, etc.) should be extendable but not modifyable. The core idea of ​​realizing the open-closed principle is to program abstractions instead of concrete programming, because abstractions are relatively stable. Let the class depend on a fixed abstraction, so modifications are closed; and through object-oriented inheritance and polymorphism mechanisms, you can inherit the abstract class and change the inherent behavior by overriding its methods. Implement new expansion methods, so it is open. "Requirements are always changing" and there is no unchanging software, so it is necessary to use the closed and open principle to close changes to meet the needs, while maintaining the stability of the packaging system within the software and not being affected by changes in requirements.

※Dependency inversion principle:Rely on abstraction, don’t rely on concreteness. The stability of abstraction determines the stability of the system, because abstraction is immutable, and dependence on abstraction is the essence of object-oriented design and the core of the dependency inversion principle. Relying on abstraction is a general principle, but sometimes relying on details is inevitable. The trade-off between abstraction and concreteness must be weighed, and the method is not static. Relying on abstraction means programming the interface, not the implementation.

※Richter substitution principle: Subtypes must be able to be replaced by their parent type. The Liskov substitution principle mainly focuses on building abstraction and polymorphism on the basis of inheritance. Therefore, only by following the Liskov substitution principle can inheritance reuse be ensured reliably. The implementation method is interface-oriented programming: abstract the public part into a base class interface or abstract class, use ExtractAbstractClass, and implement new methods in the subclass by overriding the parent class method. way to support the same responsibilities. The Liskov substitution principle can ensure that the system has good scalability, and at the same time implements an abstraction mechanism based on polymorphism, which can reduce code redundancy and avoid type discrimination during runtime.

※Interface isolation principle: Multiple customer-related interfaces are better than one general interface. There are two main methods of separation: 1. Delegation separation, by adding a new type to delegate the client's request, isolating the direct dependence of the client and the interface, but it will increase the system overhead. 2. Separate multiple inheritance and realize customer needs through interface multiple inheritance. This method is better.

The following are two principles that have not been mentioned before, and are also important principles to consider when designing.

※Demit's Law: Do not interact directly between classes that do not communicate directly with each other. If two classes do not need to communicate directly with each other, then the two classes should not interact directly. If a class needs to call a method of a class, the call can be forwarded through a third party. The first premise emphasized by Demeter's Law is that in the design of classes, each class should minimize the access rights of members. Its fundamental idea is to emphasize loose coupling between classes.

※Synthesis/AggregationReuse principle: Use synthesis/aggregation as much as possible, and try not to use inheritance. Composition and Aggregation are both special types of association. Aggregation represents a weak ownership relationship; composition is a strong ownership relationship, embodying the strict relationship between parts and wholes. Relationships, parts and wholes have the same lifecycle. Preferring composition or aggregation principles will help keep each class encapsulated and focused on a single task. This way classes and class inheritance hierarchies stay small and are less likely to grow into uncontrollable behemoths

3.2 The relationship between OO design principles

1. The key step in realizing the "Open-Closed" Principle (OCP) is abstraction. The inheritance relationship between base classes and subclasses is a reflection of abstraction. Therefore, the Liskov substitution principle is a specification of the specific steps to achieve abstraction. Violating the Liskov substitution principle means violating the "open-closed" principle, but not necessarily vice versa.

2. The "open-closed" principle and the dependency inversion principle (DIP) are the relationship between goals and means. If the opening and closing principle is the goal, the dependence inversion principle is the means to achieve the "opening and closing" principle. If you want to achieve the best "opening and closing" principle, you must abide by the dependency inversion principle as much as possible. The dependency inversion principle is the best specification for "abstraction".

3. The Liskov substitution principle (LSP) is the basis of the dependence inversion principle, and the dependence inversion principle is an important supplement to the Liskov substitution principle.

4. The interface separation principle (ISP) is also an important means to ensure the "open-closed" principle.

5. Regarding the Single Responsibility Principle (SRP), I personally think it is best to try to implement it as much as possible. The more single the responsibility, the easier it is to achieve "open-close" and Liskov substitution.

Four. The relationship between OO design principles and goals

1. Extensibility: Allows a new class with the same interface to replace the old class, It is the reuse of abstract interfaces. The client relies on an abstract interface rather than a concrete implementation class, so that this concrete class can be replaced by other concrete classes without affecting the client. The following principles enable scalability.

※Opening/Closing Principle
※Richter Replacement Principle
※Dependency Inversion Principle
※Synthesis/Aggregation Reuse Principle

2. Modification Flexibility: Modules are relatively independent and communicate as little as possible. In this way, when one module is modified, it will have little impact on other modules.

The following principles achieve modifiability.

※Open/Closed Principle
※Dimiter's Law
※Interface Isolation Principle

3. Pluggability: When a part no longer meets the needs, the old part can be pulled out and the new part inserted.

The following principles achieve replaceability.

※Opening/Closing Principle
※Richter Substitution Principle
※Dependency Inversion Principle
※Synthesis/Aggregation Reuse Principle

##5 ． OO (object-oriented) design process

1. Analyze the design and classify the functions.

#2. Abstract classes based on functions.

※ Class abstraction - In this step, we can perform specific abstraction of the class based on the "single responsibility principle". Try to make the functions of the class simple and clear.

※ Encapsulation change point – Use encapsulation to

create a boundary layer between objects, allowing designers to make modifications on one side of the boundary layer without causing adverse effects on the other side influence, thereby achieving loose coupling between layers.

#3. Design abstract base classes and interface classes.

※ When abstracting the basic base class and defining the interface, the "interface separation principle" must be followed when abstracting the interface.

※ When designing interfaces and base classes, don't always pay attention to details. Remember to program for the interface, not for the implementation.

※ The requirements of the "Richter Substitution Principle" must be met between abstract base classes and derived classes.

4. Determine the coupling relationship between classes.

#4.1 What is the basis for determining the degree of coupling?

※ To put it simply, the degree of coupling is determined based on the stability of the demand.

※ For requirements with high stability and requirements that are not easy to change, we can completely design various types to be tightly coupled, because this can improve efficiency, and we can also use some better technologies to Improve efficiency or simplify code.

※ If the requirements are very likely to change, we need to fully consider the coupling problem between classes. We can come up with various ways to reduce the degree of coupling, but in summary, it is nothing more than increasing The level of abstraction is used to isolate different classes. This level of abstraction can be an abstract class, a concrete class, an interface, or a group of classes. We can summarize the idea of ​​reducing coupling in one sentence: "Programming for interfaces, not programming for implementation.

※ When determining the coupling relationship of classes, try to consider "Dimiter's Law" and "Synthesis" /Aggregation Reuse Principle".

4.2 How to achieve dependency inversion?

※ Coupling in an abstract manner is the key to the dependency inversion principle. Abstract coupling relationships always involve concrete classes inheriting from abstract classes, and it is necessary to ensure that any

reference to the base class can be changed to its subclass. Therefore, the Liskov substitution principle is the dependency inversion principle. The basis.

※ Depend on abstraction: It is recommended not to rely on concrete classes, that is, all dependencies in the program should terminate at abstract classes or interfaces. Try to do this:

(1) No

variable should hold a pointer or reference to a concrete class. (2) No class should derive from a concrete class. (3) No method. You should not override the implemented methods in any of its base classes.

##5. Use the five principles of OO design to further optimize the design

※ For the abstraction and functions of the class, whether it satisfies the "Single Responsibility Principle" ※ For inheritance relationships and references to base classes, whether it satisfies the "Richter Substitution Principle" and "Dependency Inversion Principle"

※ For interfaces and base classes, whether the "interface isolation principle" is met

※ Generally speaking, whether the "open-closed principle" is met


Generally speaking, when designing objects, it is necessary to Fully consider the five major principles of design, but do not insist on it. Blindly pursuing the principle of satisfaction may also lead to the consumption of performance and resources of the designed system. Specific analysis and design can be carried out according to the specific situation.

The above is the detailed content of A brief introduction to the concepts and design principles of OO in Java (Collection). For more information, please follow other related articles on the PHP Chinese website!