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?
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.
(etc.)
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).
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.
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.
