What are the principles of an object-oriented approach

Five principles of object orientation?

Single Duty Principle

For the Single Duty Principle, the core idea is that a class, ideally, does only one thing, and only one causes it to change. The single-duty principle can be seen as a derivation of the object-oriented principle of low coupling and high cohesion, which defines a duty as a cause of change, and reduces the causes of change by increasing cohesion. If there are too many responsibilities, there will be more possible causes of change, which will lead to dependencies and influence on each other, thus greatly impairing cohesion and coupling. A single responsibility, in the usual sense, means having only a single function, and not implementing too many function points for the class to ensure that the entity has only one cause of its change.

Focus is an excellent quality in a person; similarly, singularity is an excellent design for a class. Intermingling responsibilities will make the code look particularly awkward and unappealing, and will inevitably lead to the risk of ugly system errors.

Open-Closed Principle

For the Open-Closed Principle, it is the core of all the principles of object-oriented, software design in the end the pursuit of the goal is to encapsulate the changes, reduce the coupling, and the Open-Closed Principle is the most direct embodiment of this goal.

The open-closed principle, the core idea is: the software entity should be extensible and unmodifiable. That is, open to extension and closed to modification.

Therefore, the open-closed principle is mainly reflected in two aspects: 1, open to extension, meaning that when there are new needs or changes, you can extend the existing code to adapt to the new situation. 2, closed to modification, meaning that the class, once the design is complete, you can independently complete its work, and do not make any attempt to modify it.

The core idea of realizing the principle of open-open-closed is to program the abstraction and not the concrete, because the abstraction is relatively stable. Let the class depends on a fixed abstraction, so the modification is closed; and through object-oriented inheritance and polymorphic mechanisms, and can realize the inheritance of the abstract class, by overriding its methods to change the intrinsic behavior, to achieve new methods of expansion, so it is open.

“Demand is always changing” there is no unchanging software, so there is a need to use the principle of closed-open to close the changes to meet the demand, while also maintaining the stability of the software internal encapsulation system, not affected by changes in demand.

Dependency inversion principle

For the dependency inversion principle, the core idea is: dependency abstraction. Specifically, high-level modules do not depend on the bottom module, they both depend on the abstraction; the abstraction does not depend on the concrete, the concrete depends on the abstraction.

We know that dependencies must exist between classes and classes, modules and modules. When there is a close coupling between two modules, the best way is to separate the interface and the implementation: define an abstract interface between the dependencies so that the high-level module calls the interface, and the bottom module to achieve the definition of the interface, as a way to effectively control the coupling relationship, to achieve the design goal of relying on the abstraction.

The stability of the abstraction determines the stability of the system, because the abstraction is unchanging. Depending on the abstraction is the essence of object-oriented design and the core of the principle of dependency inversion.

Depending on the abstraction is a general principle, while some time relying on the details is inevitable, and must be weighed in the trade-off between the abstraction and the concrete, the method is not unchanging. Relying on abstraction means programming to the interface, not to the implementation.

The Principle of Interface Separation

For the Principle of Interface Separation, the core idea is to use multiple small specialized interfaces rather than one big overarching interface.

Specifically, the principle of interface isolation is reflected in the fact that interfaces should be cohesive and “fat” interfaces should be avoided. Dependencies of one class on another class should be built on minimal interfaces, and should not force dependencies on unused methods, which is a form of interface pollution.

Interfaces effectively segregate details from abstractions, embodying all the benefits of abstract programming, and segregating interfaces emphasizes the singularity of the interface. Fat interfaces, on the other hand, have the obvious disadvantage that the type of implementation must fully implement all the methods, properties, etc. of the interface; at some point, the type of implementation does not need all the interface definitions, which is “wasteful” by design, but also potentially problematic by implementation, as modifications to fat interfaces can result in a cascade of changes to the client program, sometimes a disaster. A change to the fat interface would result in a cascade of client program modifications, which can sometimes be a disaster. In this case, decomposing the fat interface into customized methods with multiple features makes clients rely only on the methods they actually call, thus relieving clients from relying on methods they don’t use.

There are two main means of separation: 1. Delegation separation, which isolates the direct dependency of the client and the interface by adding a new type to delegate the client’s request, but increases the overhead of the system. 2. Multiple inheritance separation, which is preferable to realizing the client’s needs through multiple inheritance of the interface.

The Liskov Replacement Principle

For the Liskov Replacement Principle, the core idea is that a subclass must be able to replace its base class. This idea is embodied in the constraints on the inheritance mechanism, only if the subclass can replace the base class, to ensure that the system can recognize the subclass during the runtime, which is the basis for ensuring inheritance reuse. In the specific behavior of the parent and child classes, the relationships and characteristics in the inheritance hierarchy must be strictly grasped, and the behavior of the program will not be changed by replacing the base class with a child class. At the same time, the converse of this constraint is not true; a subclass can replace a base class, but a base class cannot necessarily replace a subclass.

The Liskov substitution principle, which focuses on abstraction and polymorphism, builds on inheritance, so inheritance reuse can only be guaranteed to be reliable if the Liskov substitution principle is followed. The way to achieve this is interface-oriented programming: abstracting public parts to base class interfaces or abstract classes, through ExtractAbstractClass, and implementing new ways to support the same responsibilities in subclasses by overriding the methods of the parent class.

The Liskov substitution principle is a design principle for inheritance mechanisms, and violating the Liskov substitution principle inevitably leads to violating the open closure principle.

The Liskov substitution principle ensures that the system is extensible, and the implementation of polymorphism-based abstraction mechanisms reduces code redundancy and avoids type discrimination at runtime.

What are the principles of object-oriented design patterns?

There are a total of seven principles to be followed while designing software using object oriented ideas, they are:


Each class should focus on doing one thing.


Subclasses are replaceable where superclasses exist.

3. DependenceInversionPrinciple

Implementations try to rely on the abstraction, not the concrete implementation.

4. InterfaceSegregationPrinciple (InterfaceSegregationPrinciple)

The client should be provided with the smallest possible individual interface, rather than providing a large total interface.

5. LawOfDemeter (LawOfDemeter)

Also known as the principle of least knowledge, a software entity should interact with as few other entities as possible.

6. OpenClosePrinciple

Open for expansion and closed for modification.

7. Composite/AggregateReusePrincipleCARP)

Try to use compositing/aggregation to achieve reuse, as little as possible with inheritance. Principle: One class has objects of another class.

Object-Oriented Design Principles

1. The Single Responsibility Principle: An object should contain only a single responsibility, and that responsibility is completely encapsulated in a class. The principle of single responsibility is to achieve high cohesion, low-coupling guidelines, is the simplest but most difficult to apply the principle of designers need to find the different responsibilities of the class and separate them.

2, open and closed principle: software entities should be open to expansion, closed to modification. Refers to software entities should try to expand without modifying the original code.

3, Richter’s replacement principle: all references to the base class must be able to transparently use the objects of its subclasses. Richter’s replacement principle suggests that in the software will be a base class object to replace the object of its subclasses, the program will not produce any errors and exceptions, and vice versa does not hold true. When applying the principle of Richter’s substitution, you should design the parent class as an abstract class or interface, and let the child class inherit from the parent class or implement the interface of the parent class, and implement the methods declared in the parent class.

4. The principle of dependency inversion: high-level modules should not depend on the underlying modules; they should all depend on the abstraction. Abstractions should not depend on details, details should depend on abstractions. Dependency inversion principle requires: to program against the interface, not against the implementation.

5. The principle of interface isolation: the client should not rely on interfaces that it does not need. In the use of interface isolation principle, you need to pay attention to the control of interface granularity, the interface can not be too small, if too small will lead to a flood of interfaces in the system, is not conducive to maintenance; interfaces can not be too large, too large interfaces will be contrary to the principle of isolation of interfaces, less flexible, inconvenient to use.

6, the principle of composite reuse: priority use of object combination, rather than inheritance to achieve the purpose of reuse. In general, if the relationship between the two classes is Has-A should use the combination or aggregation, if it is Is-A relationship can use inheritance.

7, Dimitri’s Law – also known as the principle of minimum knowledge: each software unit of the other units have only a minimum of knowledge, and is limited to those closely related to the unit of software units.

What are the six JAVA object-oriented principles?

1) Open-ClosePrinciple (OCP), the open-closed principle, talking about the design of the extension to have good support for the modification to be strictly limited. This is the most important and abstract principle, basically what we call ReusableSoftware is developed based on this principle. Other principles also provide paths to its realization.

2)LiskovSubstituitionPrinciple (LSP), Richter’s Substitution Principle, a very strict principle, the rule is that “a subclass must be able to replace the base class, otherwise it should not be designed as a subclass of it.” In other words, subclasses should only extend the base class, not hide or override it.

3) DependenceInversionPrinciple (DIP), “Design depends on abstraction rather than concretization”. In other words it means that when designing we have to think in abstractions and not just come up and start delineating which which classes I need because these are concrete. What is the benefit of doing this? Human thinking itself is actually very abstract, when we analyze a problem we don’t think about the details all at once, but rather abstractly conceptualize the whole problem, so designing for abstraction is consistent with human thinking. In addition this principle will support OCP very well, abstraction-oriented design allows us to not have to rely too much on the implementation, so that extension becomes possible, this principle is also the cornerstone of another article DesignbyContract.

4) InterfaceSegregationPrinciple (ISP), “break up large interfaces into multiple smaller interfaces”, the benefits of this are obvious, I don’t know if there is a need to continue to describe it, in order to save space, I actually just do a A small summary, if there is a need for a more in-depth understanding of the words recommended to see “Java and Patterns”, MSMVP a masterpiece! ^_^

5) Composition/AggregationReusePrinciple (CARP), the designer should first consider the composite/aggregation, not inheritance (because it is very intuitive, the first impression is “Oh, this is OO ah”). This is called “FavorCompositionoverInheritance”, and in practice compositing/aggregating brings more benefits than inheritance, so it should be prioritized.

6) LawofDemeterorLeastKnowlegdePrinciple (LoDorLKP), the Law of Demeter or Least Knowledge Principle, which was first formally utilized in the Demeter system, and is therefore defined as the Law of Demeter. It says that “an object should know as little as possible about other objects”. It is also another law about how to be Loosely-Coupled.