Which SOLID principle is about depending on abstractions rather than concretions?

Which SOLID principle is about depending on abstractions rather than concretions?

• A. Dependency Inversion Principle
• B. Interface Segregation Principle
• C. Open/Closed Principle
• D. Liskov Substitution Principle

Answer: (A)

The main idea being tested is that you should depend on abstractions rather than concrete implementations. This Dependency Inversion Principle means high‑level parts of your code shouldn’t rely on specific low‑level details; instead, both levels depend on abstract interfaces or abstract classes. By coding to an interface, you can swap the underlying implementation without touching the high‑level logic, which makes the system easier to maintain and test. A common way to apply this is through dependency injection: you provide the concrete implementation of an abstraction from the outside, so the high‑level component stays decoupled from specific details, such as which database or message sender is used. For example, a service that performs work should depend on a data access interface rather than a concrete repository class. The service calls methods on the interface, and at runtime you can supply a real repository, a mock, or a stub. This decoupling enables changing data sources or testing behavior without altering the service itself. The other principles touch related but different ideas: one focuses on keeping interfaces small and client‑specific, another on extending behavior without modifying existing code, and another on ensuring derived types can replace base types without breaking their contracts. While all are valuable, they don’t capture the specific emphasis on depending on abstractions rather than concretions as directly.

The main idea being tested is that you should depend on abstractions rather than concrete implementations. This Dependency Inversion Principle means high‑level parts of your code shouldn’t rely on specific low‑level details; instead, both levels depend on abstract interfaces or abstract classes. By coding to an interface, you can swap the underlying implementation without touching the high‑level logic, which makes the system easier to maintain and test. A common way to apply this is through dependency injection: you provide the concrete implementation of an abstraction from the outside, so the high‑level component stays decoupled from specific details, such as which database or message sender is used.

For example, a service that performs work should depend on a data access interface rather than a concrete repository class. The service calls methods on the interface, and at runtime you can supply a real repository, a mock, or a stub. This decoupling enables changing data sources or testing behavior without altering the service itself.

The other principles touch related but different ideas: one focuses on keeping interfaces small and client‑specific, another on extending behavior without modifying existing code, and another on ensuring derived types can replace base types without breaking their contracts. While all are valuable, they don’t capture the specific emphasis on depending on abstractions rather than concretions as directly.