Daniel Hiller OTOH in my experience you seldom need more than one concrete implementation, and if you do, you have a strategy and their implementations. I disagree. You are right, interfaces are often designed in "service" way, and usually implemented once or twice, but IMO it is severe mistake. Interface is meaningless if it is designed for just a few implementations. Only the interfaces which has potentially infinite number of implementations truly enable OCP. For example: interface Light { void on ( ) ; void off ( ) ; } Interface Light from example. It can have plenty of implementations, which are able to turn on and off smart lights from different vendors. Also, it can be implemented as a fake object for test purposes. It can have composite implementation, which enable management of group of lights in one shot. Any customer's demand related to turning on and off the lights can be implemented behind this interface. Such characteristic is achieved because Light is completely purified from technical details. It is true stable abstraction, the one that is always safe to depend on. In such curcumstances, if all interfaces in a system are designed with this consideration in mind, the strategy pattern, spring profiles and autowired injections become really crooked and inflexible.

Robert Martin thanks for response. I am doing my own research on applying those metrics on class-interface-level and have an interesting theory: SAP/SDP principles together with Stability/Abstractionness/Distance metrics gives simple but effective mental model for estimating maintainability/reusability of classes and detecting problems on early stages. Speaking about DI - my concern can be illustrated by example: interface ComponentA {} interface ComponentB {} class ComponentAImpl implements ComponentA { @Inject ComponentB dependency; } If there are several implementations of ComponentB visible in the context, DI container will fail in attempt to deduce the right dependency type, until you tell <b>inside</b> ComponentAImpl which exact type you are expecting there (either by specifying certain type or by different sorts of qualifiers/stereotypes). In the end, ComponentAImpl will inevitably be tied implicitly to certain ComponentB implementation. Which is violation of SDP/SAP - tie on abstractions instead of concretions. For myself, I came to conclusion that DI containers don't needed for making DI, and simple plain object composition solves the same purpose much better.

People who really deserve respect and have something valuable to say will always draw haters attention. People who have no haters behind are boring and have no own position to stand for.

Hi Robert. I am a fan of your design metrics (https://linux.ime.usp.br/~joaomm/mac499/arquivos/referencias/oodmetrics.pdf) and the "Zone of Pain" term you described in "Clean Architecture". It changed my vision on what is maintainable code drastically. However, originally you outlined those concepts for a set of classes, calling it "class categories". My question is: why can't the same metrics be applied to classes and interfaces per-se. They are a subject of reuse in OO code as well, and stable-concrete classes will inevitably be the source of pain and regressions, when the time to change something comes. Also, what do you think about DI frameworks, which do injections by means of annotations (like Spring's 'Autowired' or CDI's 'Inject')? Aren't they break stable dependencies/abstractions principles, making implicit direct dependencies between our components?