What is the difference between Chain Of Responsibility design pattern and using a simple if-elseif-else block?

Question

I was just looking up Chain Of Responsibility the other day, and I came across this example.

Basically, there is an abstract handler, and then are concrete handlers, each of which implement the handle method of the parent abstract handler. The implementation is such that at first there is a check to see if this particular handler can process the current request, and if not, then it passes on the request to its successor.

Now, I could also do the same thing using a simple if-else conditional block. To take the first example from the link above, here is how I would change it:

class SingleHandler
{
    if(request > 0 && request <= 10)
    {
        // Process request
    }
    else if(request > 10 && request <= 20)
    {
        // Process request differently
    }
    else if(request > 20 && request <= 30)
    {
        // Process request differently
    }
}

Now, my question is, what is the fundamental difference between the two? Is there any specific reason I should use Chain Of Responsibility at all, if I can provide the exact same functionality using if-else blocks? Which one is better with regards to performance, memory consumption, maintainability, scalability?

Dacoity

Answer 1

Yes, you could re-write this example to use multiple if-else-cascades. But only because it's a rather simple example.

The Chain Of Responsibility is a dynamic pattern. That means that handlers can be exchanged during run-time. This is often done in UI code where several nested controls can represent the handlers. Imagine the following scenario:

You have a window. In this window there is some kind of panel. In this panel there is a text box. You right-click the text box. The executed command depends on the hierarchy. The system would ask the first handler - the textbox - to handle the click-request. If it does not know what to do with the request, it passes it on to its parent - the panel - etc. I doubt that you want to implement this kind of scenario with an if-else-cascade. Every time you change the UI, you would have to change the cascade. That's why handler objects are used. It makes the code exchangable and re-usable.

Many patterns can be implemented in a different way. This is usual practice in low-level programming languages with no object-orientation. However, these codes are usually quite inflexible and hard to maintain. Yet, this is what makes them fast.

Beaver