Understanding the Six SOLID Design Principles: A Practical Guide for iOS Developers

The author, a mobile iOS developer at 贝壳找房装修平台, writes a reflective piece after reading "Design Patterns Zen", noting that although the book uses Java examples, the underlying principles apply equally to Objective‑C/Swift development.

The book is organized into five modules: six core design principles, 23 design patterns, comparisons between patterns, and an extension chapter. The author recommends starting with the principles, treating them as internal skills that underpin the patterns.

1. Single Responsibility Principle (SRP)

Definition: a class should have only one reason to change. The author illustrates the ambiguity of “responsibility” with a UserInfo class that mixes data and behavior, then refactors it into IUserBo (responsible for attributes) and IUserBiz (responsible for behavior).

Benefits include reduced complexity, improved readability, easier maintenance, and lower risk when changes occur.

2. Liskov Substitution Principle (LSP)

Definition: objects of a superclass must be replaceable with objects of a subclass without affecting correctness. The author discusses inheritance advantages and drawbacks, then shows a concrete example with a Father class and a Son subclass, highlighting method signature widening and the need for proper overriding.

public class Father {
    public Collection doSomething(HashMap map) {
        System.out.println("父类被执行...");
        return map.values();
    }
}

public class Son extends Father {
    // widen parameter type
    public Collection doSomething(Map map) {
        System.out.println("子类被执行...");
        return map.values();
    }
}

The author stresses that if a subclass cannot fully implement the parent’s contract, inheritance should be broken in favor of composition or aggregation.

3. Dependency Inversion Principle (DIP)

Original definition: high‑level modules should not depend on low‑level modules; both should depend on abstractions. The author uses a driver‑car analogy and shows how abstracting ICar allows swapping concrete classes like Benz and BMW without changing high‑level code.

4. Interface Segregation Principle (ISP)

Definition: clients should not be forced to depend on interfaces they do not use. The author recommends keeping interfaces small, highly cohesive, and tailored to specific business needs, illustrated with a library query system that separates simple and complex search interfaces.

5. Law of Demeter (LoD)

Also called the “least knowledge” principle: a class should know as little as possible about the internal details of other classes. The author breaks this down into three layers—limited friendships, appropriate distance, and self‑containment—emphasizing low coupling and high cohesion.

6. Open‑Closed Principle (OCP)

Definition: software entities should be open for extension but closed for modification. The author demonstrates this with a bookstore example: an abstract IBook class, concrete NovelBook, and an extension OffNovelBook that adds discount behavior without altering the original class.

Overall, the author concludes that while the six principles are abstract, they provide a solid foundation for handling unpredictable requirements, and developers should apply them flexibly rather than dogmatically.