Would this be a pipeline, a chain of responsibility, or something else?

Question

I'm building a multiprocess architecture that seems to be a strange meld of a pipeline and a chain of responsibility. Essentially, I have a chain of handlers linked up by queues. Each handler will receive an object that represents the input data, forward it to the next handler so that it can start working on it, and then determine if it can do anything with that data.

I don't believe I can call this a pipeline because one step doesn't really depend on the next. This also doesn't seem to be a traditional chain of responsibility because one handler can't prevent other handlers from handling that data. Is there a name for this design that will help me document this architecture? Or am I just going to have to call it something like "Pipeline of Responsibility"?

Answer 1

I still think it is the chain of responsibility, even with the specific of not stopping the chain.

Several patterns are very similar and they do have variations. I think the best way to see if a pattern fits a case is looking at its intent. From the GoF book:

Chain of Responsibility "Avoid coupling 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." (pg.223)

So if there's no coupling between your handler and the objects going through the chain, I don't think it matters that the object will always fall to the end of the chain, even if handled.