Programming to an interface means writing client code against a stable abstraction rather than a specific implementation. The consumer knows what operations are guaranteed but does not depend on how those operations are implemented. This improves substitutability, reduces coupling and allows implementations to evolve independently. It does not mean every class needs an interface; the abstraction should provide real value at a dependency or variability boundary.

javascript

1
Depend on behavior/contracts rather than concrete implementation details.
2
Supports implementation substitution.
3
Improves testability.
4
Reduces coupling between modules.
5
Supports dependency inversion.
6
Avoid creating interfaces purely for every class without a meaningful abstraction boundary.

Follow-up Questions

How is this related to SOLID?
What is dependency inversion?
Does every class need an interface?
When can programming to an interface become over-engineering?

Sharethis question

Share via WhatsApp, X, Facebook, LinkedIn or copy link. Open Graph preview enabled.