Python - SOLID Principles

• Single responsibility principle (SRP)

• Open-closed principle (OCP)

It emphasizes that software entities, such as classes and modules, should be open for extension but closed for modification. What does that mean? It means that once a software entity is defined and implemented, it should not be changed to add new functionality. Instead, the entity should be extended through inheritance or interfaces to accommodate new requirements and behaviors.

• Liskov substitution principle (LSP)

It dictates how subclasses should relate to their superclasses. According to the LSP, if a program uses objects of a superclass, then the substitution of these objects with objects of a subclass should not change the correctness and expected behavior of the program.

Following this principle is important for maintaining the robustness of a software system. It ensures that, when using inheritance, subclasses extend their parent classes without altering their external behavior. For example, if a function works correctly with an object of a superclass, it should also work correctly with objects of any subclass of this superclass.

The LSP allows developers to introduce new subclass types without the risk of breaking existing functionality. This is particularly important in large-scale systems where changes in one part can have effects on other parts of the system. By following the LSP, developers can safely modify and extend classes, knowing that their new subclasses will integrate seamlessly with the established hierarchy and functionality.

• Interface segregation principle (ISP)

The ISP advocates for designing smaller, more specific interfaces rather than broad, general-purpose ones. This principle states that a class should not be forced to implement interfaces it does not use. In the context of Python, this implies that a class shouldn’t be forced to inherit and implement methods that are irrelevant to its purpose.

• Dependency inversion principle (DIP)

The DIP advocates that high-level modules should not depend directly on low-level modules. Instead, both should depend on abstractions or interfaces. By doing so, you decouple the high-level components from the details of the low-level components.

 

For detailed examples, see https://www.cnblogs.com/zhangzhihui/articles/18014615 .