chain of responsibility design pattern - regd [closed]

Closed. This question is opinion-based. It is not currently accepting answers.

---

Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.

Closed 4 years ago.

Improve this question

I've seen some questions on this pattern but I am trying 开发者_C百科to understand more about this design pattern in depth. Any resources in this regard, experts commentary on what scenarios they tend to use this pattern and what scenarios to avoid and some real world examples will be really helpful in this regard. I am not looking for what is COR type but for some advanced commentary from experts. This will help me a lot in applying this pattern more responsibly next time.

---

Ok, just recently I've got some experience with this pattern in real enterprise development.

In our system we had different levels of storages (in order of precedence): base, product-specific and user-specific. Each storage held a set of XML files which described in metalanguage the elements to be shown on a webpage. Each XML file described the whole page to be shown.

When user tried to navigate to a webpage our system performed a lookup in storages of necessary XML file with regard to page ID.

Lookup ended when necessary file found, no merging algorithm was expected (entirely no merging between layers).

So for this particular situation we've introduced an interface with 1 method (in pseudocode):

ViewMetadata GetViewMetadata(string viewId);

We've simply constructed a chain of storages - implementors of this interface. The HttpHandler (for Asp.Net usecase) which was responsible for building the actual HTML representation from XML view metadata had only one single entry point to lookup mechanism: an instance of mentioned interface implementer.

All seemed to be OK (for several months actually). But

New requirement came. This requirement was about "promotion": XML file under certain circumstances ("promotion workflow") must be transferred from user storage to product storage.

Actually due to our too abstract implementation of lookup mechanism we couldn't handle this requirement - there was only one abstract entry point for handler to the whole chain of storages.

So as a result we rejected CoR pattern for this requirement. Now actual handler has explicit references to all 3 storages and when "Promote view with wiew Id = X" request comes it simply obtains the metadata directly from user storage and saves the metadata to product storage.

So, as a bottom line, I could say that CoR pattern is not a brilliant solution when you have some requirements about explicit interactions with chain elements. Too abstract interface of CoR "HandleRequest()" gives you only an opportunity to interact with an entry point of the chain.

BTW it was an opportunity to save CoR-based implementation, but the question actually was really about efforts and maintainability :)