Object Oriented Design Principles

Object-Oriented Design Principles (object-oriented design principles)

Object-Oriented Design Principles (object-oriented design principles)

LSP: Liskov Substitution Principle

The Liskov Substitution Principle

Subclasses cannot add any additional constraints that the parent class does not have
Subclass objects must be able to replace superclass objects
Example: The square class cannot be used to inherit the rectangle class, because the square class has constraints on the length and width.

OCP: Open-Closed Principle

The Open-Close Principle

The open-closed principle states that a software entity should be open for extension and closed for modification; that is, its behavior can be modified without modifying the existing source code

Two Strategies for Implementing the Open-Closed Principle

Strategy 1: Bertrand Meyer's strategy (the old way)

Reuse implementation (code), not interfaces.

A class should only be modified to correct code errors; adding or changing functionality requires creating a different class.

The new class reuses the code of the original class through inheritance
A subclass may have a different interface than a superclass

Strategy 2: New thinking in the 1990s

Reuse abstract interfaces, not implementations (code)

The interface remains unchanged, and the system functions are extended by adding new subclasses.

use abstract interfaces, where the implementation code can change;
Multiple implementations can be created and replace each other polymorphically.

SRP: Single Responsibility Principle

The Single Responsibility Principle

As far as a class is concerned, there should be only one reason for its change, that is, only one responsibility.

SRP embodies cohesion (Cohesion) Cohesion: the functional correlation between the constituent elements of a module
If a class assumes more than one responsibility, there will be multiple reasons for its change (equivalent to a class that can only perform one responsibility, perform multiple responsibilities, and there may be interference between different responsibilities)

insert image description here

ISP: Interface Segregation Principle

The Interface Segregation Principle

A client class should not be forced to depend on methods it doesn't need.

If in practical applications, if you only care about some methods in a certain class, then other methods will cause interface pollution .

The significance of the interface separation principle: According to the ISP principle, a large interface is split into smaller, more specific interfaces; so that the client class only needs to know the methods it is interested in.
The intent of the ISP principle is to keep a system less coupled so that it can be refactored, modified, and deployed more easily.
Implementation method: Split a large class into small classes with independent meaning

DIP: Dependency Inversion Principle

The Dependency Inversion Principle

High-level modules do not depend on low-level modules, both depend on abstractions

Also known as Inversion of Control (IoC, Inversion of Control), Dependency Injection

Program to the interface, not the implementation
Violation of the Dependency Inversion Principle:

insert image description here

Apply the Dependency Inversion Principle:

heuristic principle

"depends on abstraction" - all dependencies in the program should terminate in an abstract class or interface

Heuristic principles:

No variable should have a pointer or reference to a concrete class
No class should be derived from concrete classes (abstract classes can be inherited, interface classes implemented)
No method should override an already implemented method in any of its base classes

The difference between structured design and object-oriented design

structured design

The upper layer calls the lower layer, and the upper layer depends on the lower layer . When the lower layer changes drastically, the upper layer also changes accordingly, which will reduce the reusability of modules and greatly increase the development cost.