DEV Community

Stefanos Kouroupis
Stefanos Kouroupis

Posted on

3 2

Chain of responsibility pattern

This article is a couple of thoughts around specific patterns and specifically the chain of responsibility pattern. As the title obviously states. I think some basic knowledge around certain patterns is required.

In a way it's a bit of a philosophical article.

If you look up what is the recipe for making a chain of responsibility, the most common one, include the following ingredients (if you don't mind my cooking references) :

  • Decouples receiver and handler
  • Passes the request along a chain of objects

The key idea behind this pattern is to give the opportunity to more than one object to handle a specific request.

Personally I believe, that these attributes are incomplete when describing this pattern, and they are a few rogue attributes that mutate this pattern to a certain degree, those are among others:

  • define a chain in the Handler
  • define the chain in the Concrete Handler
  • the order of the chain does not affect the outcome
  • it is acceptable in some cases to let a single object to be handled by more than one object

The last one is a hazy line between the chain of responsibility and visitor pattern.

and if you suddenly add state to each operation in the chain then you start throwing mud at the water and make the line between chain of responsibility and memento (or even orchestration) patterns even more indistinguible.

State is the key here. Chain of responsibility does not have a state whereas memento and orchestration do.

Image of Timescale

🚀 pgai Vectorizer: SQLAlchemy and LiteLLM Make Vector Search Simple

We built pgai Vectorizer to simplify embedding management for AI applications—without needing a separate database or complex infrastructure. Since launch, developers have created over 3,000 vectorizers on Timescale Cloud, with many more self-hosted.

Read full post →

Top comments (0)