What is the difference between the "Open/closed principle" and the "Dependency inversion principle"?

Question

I read articles about S.O.L.I.D. but I don't see any difference between OCP and DIP. Look at this example of OCP:

http://www.oodesign.com/open-close-principle.html

The code which holds OCP also fulfils the DIP. Can anyone give me an example of code that holds OCP and not DIP?

Answer 1

I find the explanations of dependency injection and open/closed to be confusing as well. It doesn't have to be that way. Let's take a look at the article you reference: http://www.oodesign.com/open-close-principle.html

In their example, a there is a GraphicsEditor class and a hierarchy of shape classes. In the first class diagram they show, there are a bunch of methods in the GraphicsEditor for drawing each kind of shape class: drawShape; drawCircle; drawRectangle.

What happens when you want to add a Parallelogram class? You first create the new class Parallelogram and then you modify the the GraphicsEditor class to add a new method called drawParallelogram.

This is the "badness" the article refers to: adding one new shapes means you have to change existing code. You add a new subclass of Shape (Parallelogram) and you add a new method to GraphicsEditor (drawParallelogram).

That might not seem like a big deal, but it does not scale. Imagine a team of 20 developers all working on the software at once. First, every developer that adds a new shape has to remember to do two things: updated exiting code and create new code. Every new developer that joins the project will probably learn this the hard way. Second, if everyone is adding new shapes every day, it means everyone is trying to edit the GraphicsEditor class. At the same time. It's a headache. Ask me how I know that. :-) (There is also a chance of introducing a bug into existing code when it is modified.)

It would be ideal if you could add a new Shape to the system without touching ANY code in the GraphicsEditor class. That is what the article wants to demonstrate.

Look at the second class diagram in the article. Each shape now implements its own draw method. The GraphicsEditor only needs to know that there is some superclass, "Shape", and that all of its subclasses implement the method "draw". The GraphicsEditor no longer cares how many subclasses there are or what their names are. Developers are free to implement new shapes without having to modify the GraphicsEditor class. The GraphicsEditor class is now "closed". In this way, the system is "open to extension"-- no existing code has to be changed to create new shapes. Problem solved.

A simpler way to understand all of this is to learn the Visitor Design Pattern. I don't like Wikipedia's explanation of this pattern, so I will point you to another place: http://sourcemaking.com/design_patterns/visitor. I think that understanding the Visitor Pattern makes all the other terms and concepts fall into place.