The Six Principles of Object-Oriented Programming

Aug 28, 2024#设计模式121

AI Translation

This post is translated from Chinese into English through AI.View Original

AI-generated summary

Single Responsibility Principle (SRP): A class should only have one reason to change, meaning it should only be responsible for one task. For example, a Person class should only handle tasks related to a person and not unrelated tasks. Open-Closed Principle (OCP): Software entities should be open for extension but closed for modification. For example, defining a shape class and allowing different types of shapes to inherit from it without modifying the shape class itself. Liskov Substitution Principle (LSP): Subclass objects should be able to replace all parent class objects. Interface Segregation Principle (ISP): Clients should not depend on interfaces they do not need, meaning interfaces should be small and specific. Dependency Inversion Principle (DIP): High-level modules should not depend on low-level modules, both should depend on abstractions; abstractions should not depend on details, details should depend on abstractions. For example, a company class containing department classes should consider using composition over inheritance. Law of Demeter: An object should have minimal knowledge of other objects and only interact with its immediate friends.

Single Responsibility Principle (SRP): A class should have only one reason to change, that is, a class should only be responsible for one task. For example, a Person class should only be responsible for tasks related to Person, and should not handle unrelated tasks.
Open/Closed Principle (OCP): Software entities should be open for extension, but closed for modification. For example, define a Shape class, and then let different types of shapes inherit from this class without modifying the Shape class itself.
Liskov Substitution Principle (LSP): Subclass objects should be able to replace all parent class objects.
Interface Segregation Principle (ISP): Clients should not be forced to depend on interfaces they do not use, meaning interfaces should be small and specific.
Dependency Inversion Principle (DIP): High-level modules should not depend on low-level modules, both should depend on abstractions; abstractions should not depend on details, details should depend on abstractions. For example, a Company class containing a Department class should consider using composition instead of inheritance.
Law of Demeter: An object should have minimal knowledge of other objects, and only interact with its immediate friends.