Understanding of the six basic principles of object-oriented

Source: Internet
Author: User

When learning design patterns, it is always recommended to study the six principles of object-oriented first, and it is very rewarding. The following is my understanding of the six basic principles, and the official website explained there may be a way out, and I am more in the design pattern of the angle, not the object-oriented perspective of understanding, if there is any mistake, respect for the understanding.

1. Opening and closing principle

Many tutorials use the closed-open principle as the most basic principle of the six principles, that is to say, he is the core of the various principles. The open and closed principle refers to a software entity such as classes, modules, and functions that should be opened to the extension and shut down for modification .

As for this specific understanding, I have also read a lot of tutorials, and some tutorials say that when we meet new requirements, we need to extend the form of our module inheritance rather than modify the code. This explanation seems plausible, but if it does, the structure of the program will only be more complex, the business logic will only be more unclear, is a complete death. When the business changes, it is necessary to modify the code, do not need to keep only the program bloated, so that the maintainer can not understand what is useful code, what is obsolete code. I'm not convinced that the truth of the open/closed principle is to let us go to such a dead end.

For the open and closed principle, my understanding is that when we design the software, we must first understand what the future may change in the program, and what the future will not change. For things that are likely to change, we have to give the extension interfaces that can correspond to them in advance. Of course, in real-world development, even where we think these will not change, the future is likely to change, this change can only change the code, but this modification only changes the individual details, the overall structure will not change. And for possible changes, we have to give enough space to be able to expand, to allow it to expand freely, there are major changes in requirements, and the overall architecture will not be affected.

For example: In Factory mode, we encapsulate the process of creating objects so that the code created is decoupled as much as possible from the code that was called when the object pair was created. The creation process can be variable, and the calling process is often constant. After we have created an object, we need to initialize it, set some configuration, this process requires that we can extend the scope, and the need to extend the time can not affect the invocation part, so the use of Factory mode, the variable creation process is encapsulated, for the unchanged calling module.

So the core of the open-close principle is decoupling? Yes, I think the open-and-close principle is about deconstruction, but he asked us to design in a way that focuses on the pre-judgment of what is going to change and where to leave room for change. He emphasizes decoupling the mutable parts, using an extended approach rather than modifying them to respond to changes, thus ensuring that the program as a whole does not change greatly.

The open and closed principle is especially important for development frameworks, reusable components such as jars, DLLs, and JS plug-ins, because these components must allow enough space for callers to expand their business. So when we develop this component, the API is the most difficult to design, because the API we design must be able to satisfy the caller's full extension to him, so that the caller can implement their own requirements without modifying the component code.

2. the Richter replacement principle

This is a very simple principle, and when it comes to using interfaces, we have to make sure that subclasses can replace any place where the parent class appears . In purely literal terms, the parent interface must ensure that all subclasses can implement the requirements, not one subclass of the class.

For example, HashMap and Linkedhashmap in Java are subclasses of map. But the order of the HashMap is random, and the linkedhashmap is fixed. When we need to use a map, this map does not require the key sequence to be controllable, we can declare:

Map Createmap () {
return new HashMap ();

But we ask that the order be controlled, if so:

Map Createmap () {
return new Linkedhashmap ();

The above code is not very good, because HashMap is also a subclass of map, but he can not meet our needs, so here must declare the return value type is linkedhashmap. For example, when we design the interface method, if the caller needs a linkedhashmap, we cannot make the declaration of the interface in the HashMap type.

Of course, the Richter replacement principle can also be viewed from a design point of view, stressing that when we design we need to ensure that the parent class is defined, it should overwrite all the methods of the business abstracted by the interface, without requiring his subclass to add additional extensions, and each subclass should implement all the interfaces in the parent class. Only in this way can we ensure that what we have designed is extensible.

The open and closed principle is extended, and the Richter substitution principle ensures that extensions that are inherited in this way are possible, otherwise you cannot use inheritance to extend the program.

For example, we use template mode, do a class as the parent class algorithm template, a subclass inherits this template, and successfully completed the run, but another subclass inherits the template class, but cannot run, finally found that the program cannot ensure that all subclasses of the inherited template can replace the parent class, which is a failed template pattern.

From the perspective of the face object, the Richter substitution principle is that subclasses can replace the parent class, but from the perspective of the face component, it is to make sure that the API of the component is complete and unchanging, and that the subclass and the outside world are fully decoupled, only in this way can we develop the extension to run without destroying the original framework.

3. Dependency Inversion principle

This principle is also about decoupling, he refers to the high-level modules do not rely on low-layer modules . This is a purely interface-oriented, module-oriented approach, because object-oriented, the objects themselves and the outside world is decoupled, because the encapsulation characteristics of their own properties are encapsulated, so there is no coupling with other objects (such as C + + friend) But each object is still coupled, the strongest coupling is the inheritance coupling, the object combination is at least a light coupling, inheritance is a high coupling. Dependency inversion is to reduce the coupling of the object, the high-level module can not inherit the underlying module, the need for the underlying things are injected into the outside world and not by themselves, but also call the use of the interface call, rather than rely on the implementation, and because it is an interface call, the implementation of the module may be arbitrarily replaced.

This reduces the coupling of each module and ensures the implementation of the Richter replacement principle. What's the use of implementing the Richter replacement principle? Of course, it is easy to expand.

456. Single principle of responsibility, minimum knowledge principle, interface isolation principle

These principles are very similar, put together to say. These classes are focused on deconstruction (of course, the open and close principle, the Richter substitution principle, the dependency inversion principle). These principles are basically the emphasis on deconstruction, but the point of view is not the same, they say that a class is responsible for only one responsibility , one class to another class dependency should be based on the smallest interface, the caller should not rely on the interface it does not need, An object should have a minimal understanding of other objects . What they are saying is that the class and interface design should minimize the coupling problem.

Summary: Relationships with design patterns

Briefly introduce these basic principles, and say my understanding of them and design patterns. When we are learning design patterns, have you ever wondered why you should learn this and what are the benefits of learning design patterns? I often find many inexperienced programmers in my work, learning design patterns in order to learn design patterns, using design patterns for design patterns, and inexperienced programmers. In fact, every program developed by programmers is based on demand, only to understand the fundamental needs of a project to use the meaning of design patterns.

The six principles, the most important is the opening and closing principle, my understanding of the principle of closure, you do not need to do in every detail on the expansion of open, to modify the closure, but should be expanded in order to face the expansion. When there is such a demand, such as a project business, the algorithm may be a major change, or the development of itself is a component, this is only need to expand, and the extension should use design patterns to achieve this requirement, that is, the use of design patterns and our usual development, are to meet the needs.

The use of design patterns does not necessarily improve the structure and maintainability of the code, so experienced programmers use design patterns as required. The six basic principles can better help us analyze how to determine whether to use design patterns. In fact, the use of design patterns I suggest no recruit wins, to meet the project's additional requirements (such as the extension, reusability, high maintainability) are good strokes, no need to control what he is the design mode.

Understanding of the six basic principles of object-oriented

Contact Us

The content source of this page is from Internet, which doesn't represent Alibaba Cloud's opinion; products and services mentioned on that page don't have any relationship with Alibaba Cloud. If the content of the page makes you feel confusing, please write us an email, we will handle the problem within 5 days after receiving your email.

If you find any instances of plagiarism from the community, please send an email to: info-contact@alibabacloud.com and provide relevant evidence. A staff member will contact you within 5 working days.

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.