I have read in an article DIP in the Wild that "When Robert Martin first discussed the DIP, he equated it a first-class combination of the Open Closed Principle and the Liskov Substitution Principle".

As all of them are in scope of SOLID Principles, doesn't that mean that we have some redundancy within SOLID if one of the principles is a "combination" of two other SOLID principles or am I taking it too literally?

  • I do not see any relation between DIP on the one hand and LSP or OCP on the other hand. LSP and OCP are specifically about inheritance and how to apply it properly. DIP is about decoupling, about controlling dependencies between caller and callee. Totally different things. Commented Mar 5, 2022 at 12:54
  • 2
    Dear SE fellows reading this question: There seems to be an epidemics of close votes on SE. We have here a well formulated precise question and there are already 2 close votes because more details would be needed? Which ones: it’s a question about abstractions! If 90% of the really interesting question get close-voted like in the past weeks, people will no longer ask such questions here. What will be the future of this community then, considering that we’ve already transferred many topics (security, open source, …) to other communities?
    – Christophe
    Commented Mar 5, 2022 at 13:16
  • @Christophe: I didn't close vote, but I was really on the fence. The question isn't particularly interesting, other than as yet another example of how people overthink SOLID. Commented Mar 5, 2022 at 14:32
  • 1
    @RobertHarvey - "the question isn't particularly interesting" - well, that depends on your interests. For example, it's interesting if you've thought about the flaws of SOLID and how you'd go about formulating (or uncoverig) a set of principles that has more clarity and is less prone to inducing widespread confusion :) But I acknowledge this might be somewhat of a niche interest. Commented Mar 5, 2022 at 14:47
  • @FilipMilovanović Interest level here is not 100% subjective. There's so much written down about SOLID (here and elsewhere) that I doubt there's much good left to say. "Tell me about SOLID" is just the ultimate no-thought-required question that people interviewing a job candidate in 3.5 minutes tend to use. Wish some of the energy people devote to that stuff would get devoted to, say, relational databases or numeric representation formats / tradeoffs. I can't use Liskov Substitutability to improve a slow database query. Commented Mar 7, 2022 at 16:09

3 Answers 3


The link to the DIP article at the top of the referenced page is broken; here's an archived one so that you can read what Robert Martin actually wrote.

"[...] doesn't that mean that we have some redundancy within SOLID if one of the principles is a "combination" of two other SOLID principles or am I taking it too literaly?"

The focus of each SOLID principle is different. Now, in some ways, they are a more targeted expression of more general principles (abstraction, encapsulation, cohesion, loose coupling, modularity, etc.), and there's some overlap on that level, so if there's any sense or manifestation of redundancy, that's where it's coming from. But, if you think of these as of building blocks, we have a bit of a "the whole more than the sum of its parts" situation here, so this doesn't mean that there's the kind of redundancy where you could throw out one of the SOLID principles and still end up with a system of principles that's equivalent (where you could reconstruct the missing principle from the others).

DIP tells you how to control the direction of dependencies when you need to, by inserting an abstraction1 between the interdependent components.

Liskov is actually quite technical if you go beyond the two-line summary, and it tells you what it means for something to be a subtype (in other words, how to check if your derived type actually makes sense, given an established base type). It's a behavioral definition of subtyping, where the subtype is expected to confirm to the abstract behavior specified by the parent type. So, again, an abstraction1 of some sort is involved.

OCP advises to strategically pick the kinds of changes against which parts of your code can be closed, while leaving other parts open to extension, substitution/modification (so, you can't "future-proof" and close against arbitrary kinds of changes; you have to choose based on your understanding of the problem domain). To achieve this, there has to be some kind of a stable abstraction1 (an extension point) separating the fixed part and the modifiable part. For a better intuitive understanding, think any 3rd party code that allows you to "plug in" your own code into it - maybe you derive from a base class provided by a framework, or maybe you just pass in a lambda to a library function.


You see how they all have a very different "feel", how they address a different aspect of design?

1 Note that, in general, "abstraction" doesn't necessarily mean an abstract class or an interface, although it's commonly one or the other (could be a concrete base class, a data structure, a function signature, a set of conventions, a type specification, etc.). It doesn't matter so much what kind of construct it is, but rather that it embodies (in the code) an idea that is more abstract or high-level than the things that depend on it (call it, implement it, adhere to it).

Now, the principles do interact with each other in practice (sometimes even antagonistically!), so you do end up considering them together, in a kind of a balancing act. For example, because DIP (usually) involves coming up with a polymorphic abstraction (subtyping), that abstraction-implementation pair should take Liskov into consideration, and because of the structure arising from applying DIP (a structure which is, just in terms of the relationships between elements, similar to, say, the Strategy Pattern), there's some "open-closedness" involved - your code will easily accommodate certain kinds of changes (some aspects will be pluggable/exchangable, other aspects will not be affected), but not other kinds of changes (and not necessarily in the way you want). And by doing this separation, you're dividing responsibilities among different elements in your code, etc.

Note also that you could go the other way around - to achieve OCP, you'll often need to invert some dependency, etc. So, while this interaction does influence your decisions, again, as each principle focuses on a different aspect of design, abandoning one of them as ostensibly redundant would reduce their power as a design thinking toolkit.

P.S. Just to be clear, this doesn't imply that SOLID is the most optimal set of design principles you could theoretically come up with; there could be a better system (but IMO, the improvement probably wouldn't be drastic, but of a more incremental nature).

  • DIP tells you how to control the direction of dependencies It has nothing to do with the direction. This nonsense is repeated over and over again.
    – ᄂ ᄀ
    Commented Apr 4, 2022 at 5:16
  • @ᄂᄀ - well, you're wrong (dependency direction is fundamental to it, it's not called "inversion principle" for nothing), but please do elaborate - perhaps we don't mean the same thing by "direction" Commented Apr 4, 2022 at 6:43
  • perhaps we don't mean the same thing by "direction" This is hilarious. The word "direction" has a very clear definition, just as "inversion". Try any explanatory dictionary if you have problems understanding it. As usual, the proponents of the nonsense title introduced by Martin are trying to evade its nonsensical essence by "we have our own meaning for words".
    – ᄂ ᄀ
    Commented Apr 4, 2022 at 8:16
  • @ᄂᄀ So, what's the problem then? I'm not questioning the straightforward meaning of the word "direction", I'm asking what is it that you think it specifically refers to within the context of DI terminology, and how this leads to your assertion that DIP has nothing to do with the direction of dependencies. Cause, again, you are simply wrong. Nevertheless, I want to hear you out. You say you don't like DI as a name - what name do you prefer? Commented Apr 4, 2022 at 9:49
  • This is hilarious. You are unable to demonstrate neither direction, not its inversion. Instead, you are trying to appeal to "DI terminology" while this "terminology" is nonsense in the first place. Terminology, you say? Provide a clear, formal definitions of the concepts "direction" and "inversion".
    – ᄂ ᄀ
    Commented Aug 17, 2023 at 7:05

The only redundancy in SOLID I recognize would be in SRP and ISP.

The Interface Segregation Principle is basically the Single Responsibility Principle for interfaces.

SOLID is about object oriented programming. The article referred to in the question suggests its scope is a lot broader and it provides a questionably wide description of what DIP would represent. I read parts of it and I do not assess it as helpful or even true to what is understood by SOLID principles throughout the industry. I suggest you look further if you want to get to grips with SOLID principles.

  • I must admit that this is a very interesting point of view. So a kind of meta-redundancy.
    – Christophe
    Commented Mar 5, 2022 at 18:11

There is no overlap between the principles, but they form a cohesive whole. The fact that they work better when used together, mutually reinforcing their strength, should not be misunderstood as an overlap.

In fact, you may use DIP without OCP and without LSP. It’s just that you won’t enjoy the full benefits:

  • You could perfectly inject an abstraction that is not fully closed and needs to be modified more than desired (e.g. a visitor that needs to be modified depending on the classes it may have to visit). You’d just might have more maintenance that you would like.

  • You may as well use DIP without LSP. In many case DIP still works when strengthening preconditions or even relaxing post-conditions and still enjoy the benefits of DIP. It’s just that you’ll have to be more careful about your assumptions when using the injected abstraction.

  • Hm... I guess it depends on what you mean by "overlap", or as the OP put it, by "redundancy". This makes me think that I should revise the language in my own answer. From my perspective, the level where there's no overlap is "each focuses on a different design problem" (and you can consider them independently in the way you described), but "under the hood" (on a deeper level) there's overlap in the underlying design principles and design techniques. (I.e., I don't consider SOLID to be the most fundamental, bedrock set of principles - in the sense that you couldn't break them down further). Commented Mar 5, 2022 at 13:22
  • I edited my own answer to clarify what I mean; I don't think our positions are very different overall (perhaps they are in some details). I originally overlooked how the last sentence in the question ("[is] one of the principles is a "combination" of two other SOLID principles[?]") could lead to misinterpreting what I meant if not addressed explicitly. Commented Mar 5, 2022 at 14:38
  • @FilipMilovanović I indeed also think that our positions are not so far away, now that you've clarified. R.C. Martin in his original paper was not fully clear either imho; he seemed to suggest that the third is the generalisation of consequence of the two first. So I wanted to underline that this is not the case and that DIP has a meaning on its own, even if we can find some synergies and ex-post find plausible relationship at a higher order ;-)
    – Christophe
    Commented Mar 6, 2022 at 23:31

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.