-1

I think it's fair to say that they are quite similar to each other. The only difference that I know is the intent.

Chain of Responsibility: Avoid coupling between the sender of a request to its receiver by giving more than one object a chance to handle the request. Chain the receiving objects and pass the request along the chain until an object handles it. Not all objects may get chance or be able to handle the request.

Decorator : Attach additional responsibilities to an object dynamically. Decorators provide a flexible alternative to sub-classing for extending functionality. All decorator objects handle the request by enhancing the data in their own way.

But is there a difference if implementation? Apart from the fact that in Chain of responsibility you could break the chain at any point?

The following is an example of Decorator Pattern. But if you had asked me to write an example of Chain of responsibility, I could have written the same example.

Yes, I could have also added the condition where I check if the request is to be forwarded further and then break the chain, if not. But is that a mandatory thing for it to qualify as a Chain of Responsibility Pattern?

If it's not then doesn't the following serves as an example of both Chain of Responsibility and Decorator pattern? Does chain of responsibility differ only by an extra if condition that check if it is to be forwarded? Or is there more to it?

public interface IStream
{
    void write(string data);
}

public class CloudStream : IStream
{
    public void write(string data)
    {
        Console.WriteLine("Writing to cloud storage..");
    }

}
public class EncryptStream : IStream
{
    private IStream stream { get; set; }

    public EncryptStream(IStream stream)
    {
        this.stream = stream;
    }

    public void write(string data)
    {
        Console.WriteLine("Encrypting stream..");
        var encryptedData = Encrypt(data);
        this.stream.write(data);
    }

    private object Encrypt(string data)
    {
        return data; // return encrypted data
    }
}

public class CompressStream : IStream
{
    private IStream stream { get; set; }

    public CompressStream(IStream stream)
    {
        this.stream = stream;
    }

    public void write(string data)
    {
        var compressedData = Compress(data);
        Console.WriteLine("Compressing stream..");
        this.stream.write(data);
    }

    private object Compress(string data)
    {
        return data;
    }
}
10
  • 2
    The Wikipedia articles for Chain of Responsibility and Decorator explain the differences quite well, including the differences in implementation. I'm not sure what we could add here. Jun 28, 2021 at 14:16
  • 1
    What you just said. The software patterns are already well-known for solving multiple problems and having overlap. That's part of the reason they are useful. Jun 28, 2021 at 14:24
  • 1
    Software development attracts people who like to be precise. The problem, of course, is that only certain things about computers are precise. There's no "right" way to write software, and if there is, just wait five minutes and it will change. Jun 28, 2021 at 14:25
  • 1
    Using a precise definition of a software pattern when attempting to apply a software pattern to a problem isn't going to work. Instead, evaluate the software pattern within the context of the specific problem you're trying to solve, and choose the pattern that is the best fit. And, since the catalog of software patterns is not comprehensive, know when to write your own code. Jun 28, 2021 at 14:29
  • 1
    I had already seen that stackoverflow link. That's how I know the difference in the intent. I think I am at peace now. Thank you for confirming. Jun 28, 2021 at 14:40

1 Answer 1

1

Interesting question.

Yes, I could have also added the condition where I check if the request is to be forwarded further and then break the chain, if not. But is that a mandatory thing for it to qualify as a Chain of Responsibility Pattern?

Yes, according to GoF’s strict definition:

if the ConcreteHandler can handle the request, it does so; otherwise it forwards the request to its successor.

But is there a difference if implementation? Apart from the fact that in Chain of responsibility you could break the chain at any point?

Their class diagrams are also slightly different:

  • Chain of responsability pattern: Class diagram of the Chain of responsability pattern.

  • Decorator pattern: Class diagram of the Decorator pattern.

As you can see, the successor property of the Chain of responsability references the class itself, while the component property of the Decorator pattern references another class.

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.