The 'D' in SOLID stands for?

The 'D' in SOLID stands for?

• A. Dependency Inversion Principle
• B. Design for Reuse Principle
• C. Data Abstraction Principle
• D. Distributed Objects Principle

Answer: (A)

Dependency Inversion Principle is the idea that high-level parts of a program shouldn’t be tightly tied to low-level details. Instead, both levels rely on abstractions—interfaces or abstract classes. The result is looser coupling, so you can change or replace the concrete implementations without touching the high-level logic. In practice, this means designing components to depend on abstractions rather than concrete classes. For example, consider a service that sends messages. If it directly creates and uses a specific EmailSender, the service is tied to email delivery and hard to test or switch to something else. If the service depends on a general interface like MessageSender with a send method, and both EmailSender and SmsSender implement that interface, you can swap how messages are delivered by providing a different implementation at runtime (often via dependency injection). The high-level service stays the same; only the concrete implementation changes, keeping the system flexible and easier to maintain. Other ideas mentioned—designs aimed at reuse, data hiding abstractions, or distributed object concerns—describe valuable concepts, but they are not the principle referred to by the D in SOLID.

Dependency Inversion Principle is the idea that high-level parts of a program shouldn’t be tightly tied to low-level details. Instead, both levels rely on abstractions—interfaces or abstract classes. The result is looser coupling, so you can change or replace the concrete implementations without touching the high-level logic.

In practice, this means designing components to depend on abstractions rather than concrete classes. For example, consider a service that sends messages. If it directly creates and uses a specific EmailSender, the service is tied to email delivery and hard to test or switch to something else. If the service depends on a general interface like MessageSender with a send method, and both EmailSender and SmsSender implement that interface, you can swap how messages are delivered by providing a different implementation at runtime (often via dependency injection). The high-level service stays the same; only the concrete implementation changes, keeping the system flexible and easier to maintain.

Other ideas mentioned—designs aimed at reuse, data hiding abstractions, or distributed object concerns—describe valuable concepts, but they are not the principle referred to by the D in SOLID.