Common Object-Oriented Design Principles and Their Significance

In software development, timeless design and development principles guide system architecture regardless of programming language. This article collects and explains several widely‑used object‑oriented principles, describing their definitions, analyses, benefits, and concrete examples.

Single‑Responsibility Principle (SRP)

Each class should have only one reason to change, promoting low coupling and high cohesion. Responsibilities are divided into data and behavior, and separating them improves readability, maintainability, and reduces risk when modifications occur.

Open‑Closed Principle (OCP)

Software entities (classes, modules, functions) should be open for extension but closed for modification. Extending behavior without altering existing code is achieved through abstraction, enabling stable and adaptable systems.

Liskov Substitution Principle (LSP)

Objects of a superclass must be replaceable with objects of a subclass without affecting program correctness. This ensures reliable inheritance and supports the open‑closed principle by allowing polymorphic use of subclasses.

Interface Segregation Principle (ISP)

Clients should not be forced to depend on interfaces they do not use. Large interfaces are split into finer‑grained ones so each client only sees the methods it needs, reinforcing SRP and reducing unnecessary coupling.

Dependency Inversion Principle (DIP)

High‑level modules must not depend on low‑level modules; both should depend on abstractions. Details depend on abstractions, not the other way around. Typical implementations include constructor, setter, and interface injection.

/**
 * 依赖注入是依赖AbstractSource抽象注入的，而不是具体
 * DatabaseSource
 */
abstract class AbstractStransformer {
    private AbstractSource source;
    /**
     * 构造注入(Constructor Injection)：通过构造函数注入实例变量。
     */
    public void AbstractStransformer(AbstractSource source) {
        this.source = source;
    }
    /**
     * 设值注入(Setter Injection)：通过Setter方法注入实例变量。
     * @param source : the sourceto set
     */
    public void setSource(AbstractSource source) {
        this.source = source;
    }
    /**
     * 接口注入(Interface Injection)：通过接口方法注入实例变量。
     * @param source
     */
    public void transform(AbstractSource source) {
        source.getSource();
        System.out.println("Stransforming ...");
    }
}

Composite/Aggregate Reuse Principle (CARP)

Prefer object composition or aggregation over inheritance to achieve reuse. Composition offers lower coupling and runtime flexibility, while inheritance can lead to tighter coupling and reduced extensibility.

Law of Demeter (LoD)

Also known as the Least Knowledge Principle, it advises that a class should only talk to its immediate friends (itself, method parameters, its fields, objects created within the method, and elements of collections it owns). This reduces coupling and improves maintainability.

Q&A Highlights

Additional notes cover other design principles such as encapsulating change, favoring composition over inheritance, programming to interfaces, and the “Hollywood principle” (don’t call us, we’ll call you). Example scenarios illustrate how these principles manifest in real code and design patterns like Facade and Strategy.

Source: https://www.cnblogs.com/pengdai/p/9151800.html (content reproduced with attribution).