DEV Community

Discussion on: Open Closed Principle

Collapse
 
brucknert profile image
Tomas Bruckner

Does it really solve anything though? Now you have to create a factory that has the same if statement as before:

if(type == "JPEG") {
  return new PhotoJpeg();
}    
else if (type == "PNG"){
  return new PhotoPng();    
}
else {
  return new PhotoGif();
}
Enter fullscreen mode Exit fullscreen mode

When you want to add a new type of image format e.g. webp, you still have to break the 'closed for modification' principle, because you need to change the code of your factory and add new 'if'.

So instead of having one class you now have 1 interface, 3 classes for image types, and 1 factory. When you want to check what types of image formats are available, you have to check all classes that implement the Photo interface. To add a new format, it's also harder because there may be a class already but it is not in a factory yet. Maybe you want to add ".jpg" instead of ".jpeg". Maybe you want to change behavior that for all types even the uppercase format is valid so ".JPG" works as well. How do you share it? You create more classes and add inheritance and now it is even harder to know what's going on. Just layers and layers of abstraction that makes everything really difficult to see.

In the original code, you could tell right away what were all the capabilities of your code and what was going on. The new "better" code is much more complicated, you can't tell what's going on if you don't go through x files and it hasn't achieved anything, because you still need to break the closed for modification principle.

Collapse
 
amrsaeedhosny profile image
Amr Saeed • Edited

I don't know if I got ur point but I'll try to explain further:

This code:

class PhotoViewer{  
    void openPhoto(String type){
        if(type == "JPEG"){      
            System.out.println("Open JPEG photo!");
        }    
        else if(type == "PNG"){
            System.out.println("Open PNG photo!");    
        }
        else{
            System.out.println("Photo type is not supported!");
        }
    }
}
Enter fullscreen mode Exit fullscreen mode

is replaced with this one:

class PhotoViewer(){  
    void openPhoto(Photo photo){    
        photo.open();  
    }
}
Enter fullscreen mode Exit fullscreen mode

You don't have to check anything in the latter code. PhotoViewer only cares about dealing with any instance of a Photo class to open it. So, you can have an array of different photos and open any one of them using PhotoViewer. If you try to add a new Photo type you don't have to check anything or change the behavior of the PhotoViewer, just add a new photo. Also, you've to know that if you decided to use the simple Factory pattern to create your photo objects it will obviously violate the Open-Closed principle as you said. Check this link for more details:
softwareengineering.stackexchange....

Violating the Open-Closed principle to create objects using Factory doesn't mean you've to make other parts violate it. This part of the example only explains what the Open-Closed principle says.

Collapse
 
brucknert profile image
Tomas Bruckner • Edited

I can see that I wasn't clear enough so I will try to explain better.

You have a string representing a photo and PhotoViewer class just as you had before.

var photoType = "jpg";
var photoViewer = new PhotoViewer();
Enter fullscreen mode Exit fullscreen mode

in the first code, you open the photo simply like this

photoViewer.openPhoto(photoType);
Enter fullscreen mode Exit fullscreen mode

but you had "ugly" if inside openPhoto method that you didn't like.

So you refactored it to get rid of it. You created a bunch of classes, an interface. But now you have a problem because you still only have the string representing the photo. How can you change string photoType to correct class implementing Photo interface?

var photoType = "jpg";
var photoViewer = new PhotoViewer();
var photo = ???  // how to solve this?
photoViewer.openPhoto(photo);
Enter fullscreen mode Exit fullscreen mode

you can either create if statement

if (photoType == "jpg") {
  photoViewer(new JpegPhoto());
} else if (photoType == "png") {
 ...
}
Enter fullscreen mode Exit fullscreen mode

so you have the same "if" as before. But now you have a bunch of classes and an interface on top of that. So your code still breaks the principle the same way. There are just more classes + higher abstraction = complex code, but you still haven't solved the core issue why you even started refactoring in the first place and that is that it breaks open-closed principle.

You can also add even more abstraction and make the code even more complex using factory pattern. But again, yes, now the previous code doesn't break the principle:

var photoType = "jpg";
var photoViewer = new PhotoViewer();
var photoFactory = new PhotoFactory()
var photo = photoFactory.create(photoType);
photoViewer.openPhoto(photo);
Enter fullscreen mode Exit fullscreen mode

But once again, it is just shifting the if somewhere else (this time to the factory).

public class PhotoFactory {
  public Photo create(String photoType) {
    if (photoType == "jpg") {
       return new JpegPhoto();
    } else if (photoType == "png") {
       return new PngPhoto();
  }
}
Enter fullscreen mode Exit fullscreen mode

So once again, your code still breaks the principle.

So you had a code that was breaking the principle. You made some changes, added a lot of abstraction and the core problem that your code is breaking the principle is still there.

I just don't understand why shifting and hiding the problem under layers of abstraction is called better code.

Thread Thread
 
amrsaeedhosny profile image
Amr Saeed • Edited

Now I got your point. Actually, you're right about that. The factory pattern somehow violates the open-closed principle, but its violation is not the worst and you can deal with it if you apply the pattern correctly. You can't always apply the principle as the book says. But you can always try to reduce and control the violation.

Imagine if the photo has open, close, and share functions.

class PhotoViewer{  
    void doSomethingToPhoto(String type, String action){
        if(type == "JPEG"){      
            if(action == "open") {
                // do something
            } else if(action == "close") {
                // do something
            } else if(action == "share"){
                // doe something
            }
        }    
        else if(type == "PNG"){
            if(action == "open") {
                // do something
            } else if(action == "close") {
                // do something
            } else if(action == "share"){
                // doe something
            }
        }
        else{
            if(action == "open") {
                // do something
            } else if(action == "close") {
                // do something
            } else if(action == "share"){
                // doe something
            }
        }
    }
}
Enter fullscreen mode Exit fullscreen mode

You can see that this is one of the worst things you can do to add those functionalities. So, the correct way is to create a Photo interface and force every new photo type to implement. Even if that shifted the violation to use the Factory pattern. You can control its behavior and limit the problems to the creation only. Because it's a well-known design pattern.

I hope I answered your question clearly and I will try to edit the example to become clearer. Also, try to read this article it's useful and talks about that:

sergeyzhuk.me/2018/01/25/factory-m...

Thread Thread
 
leadegroot profile image
Lea de Groot • Edited

Drop the if and generate the class name, quick cut:

If (class_exists($phototype .  ‘Type’)) {
  (new  $phototype)-> open();
} else {
  echo 'Error: '.$phototype.' unsupported';
}
Enter fullscreen mode Exit fullscreen mode

(Untested PHP, but I’m mobile right now)