Design Pattern Principles: The Seven SOLID Rules, Dependency Inversion, and Inversion of Control

Click the above “Java Interview Questions Selected” to follow the public account.

Interview practice, fill gaps.

>> Notice: Past interview questions are organized in the public account menu under “Interview Questions”; feel free to browse.

The Seven SOLID Principles

Some claim that design patterns are dead because frameworks like Spring handle class and object management, allowing developers to focus on functionality rather than design. Here are the seven SOLID principles:

Open‑Closed Principle

Single Responsibility Principle

Dependency Inversion Principle

Least Knowledge Principle

Interface Segregation Principle

Composite/Aggregate Reuse Principle

Liskov Substitution Principle – any place a base class can appear, a subclass can also appear

Dependency Inversion

Imagine designing a car: first wheels, then chassis, then body, then the whole car. This creates a chain of dependencies where the car depends on the body, the body on the chassis, and the chassis on the wheels, making maintenance difficult.

If the market demands larger wheels, you must modify the chassis, the body, and the entire car—an extensive ripple effect.

Instead, start with the overall shape of the car, then design the body, then the chassis, and finally the wheels. Now the dependency direction is reversed: wheels depend on the chassis, chassis on the body, and body on the car.

When the wheels change, only the wheel design needs updating, avoiding widespread changes. This is the Dependency Inversion Principle: high‑level modules define what is needed, while low‑level modules implement it without the high‑level modules knowing the details.

Inversion of Control (IoC)

IoC is a concrete application of the Dependency Inversion Principle, typically realized through Dependency Injection (DI). The relationship among these concepts can be visualized as follows:

Using the car example, we define four classes: Car, Body, Chassis, and Tire, then instantiate the car. In the initial design, each higher‑level class directly constructs its lower‑level dependencies, so changing the Tire class forces changes throughout the hierarchy.

By applying constructor‑based Dependency Injection, only the Tire class needs modification; other classes remain untouched, improving maintainability and enabling independent team development and unit testing.

Other injection methods such as setter injection or interface injection share the same core idea: achieving control inversion.

IoC Container

The code that creates the Car instance in the earlier example is effectively an IoC container.

Manually writing many new statements is cumbersome; an IoC container automates object creation based on a configuration (XML or code), eliminating repetitive initialization code.

The container also abstracts away the details of how instances are created. Instead of manually constructing objects from the bottom up, the container starts from the top‑level component, resolves dependencies depth‑first, and instantiates each required class automatically.

This article provides a clear explanation of control inversion; focus on the design concepts rather than specific frameworks.

Source: zhihu.com/question/23277575/answer/169698662

Recent Issues

[60] Can repeatable read prevent phantom reads? (MySQL Interview Part 3)

[61] MySQL row lock vs. table lock (MySQL Interview Part 4)

[62] Explain inner join vs. outer join in MySQL (MySQL Interview Part 5)

[63] MySQL indexes, B+ tree principles, and indexing rules (MySQL Interview Part 6)

[64] MySQL CPU 100% issue troubleshooting (MySQL Interview Part 7)

Instead of searching for questions online, follow us now!