71: Design Patterns: Chain Of Responsibility.

The chain of responsibility behavioral pattern allows you to setup a series of possible results that you can initiate from a single location without worrying about what code will provide the result. Usually this pattern describes a single outcome but there can be more. Many times, this pattern works with the composite design pattern in order to know which object to call next. The composite pattern provides a nice hierarchy of objects but you don’t have to use that pattern or that structure. As long as you have some means to provide one or more possible result handlers that each know about the next handler in line, then you have the means to follow this pattern. Your code just calls the first handler and it can choose to do something or move to the next. These are just method calls and a handler is some object that decides it’s the best object to deal with the method call. If not, then the object passes control to the next object by calling the same method on the next object. The order that the handlers are called is very important and you normally want to make sure that the possible handlers are ordered so they’re looking at very specific criteria first, then a little broader criteria, then a little more, and so on, until you may want some handler that acts as a catch-all. This pattern doesn’t guarantee that your request will be handled or which object will handle the request. That flexibility allows you to reduce coupling between your objects. If you know exactly which object you want to call to process a method call, then this pattern is not for you. The decorator design pattern also calls from one object to the next. There is a big difference between these two patterns though. The decorator is trying to add new features or behavior to a base object. The chain of responsibility is just trying to figure out who will handle the request. Listen to the episode for more or read the full transcript below. Transcript The basic description says that this pattern avoids coupling the sender of a request with its receiver by chaining multiple receivers and giving each one a chance to handle the request. Let’s say you have a group of about 20 people that you want to organize into teams. A common way to do this is to select team captains who take turns selecting their team members. That’s actually opposite of how this pattern works. Here’s a better example that still uses team captains. You first select a few team captains and give each captain some criteria for selecting their team members. Maybe the first captain is told to select anybody wearing sandals. Another captain should select anybody with the color blue. Another should select anybody with short hair. And another should select anybody. What happens? In particular, which team will Bob join. Bob has short hair and is wearing blue sandals. The order here is very important. Because Bob meets the criteria for all the team captains, he’ll end up on the first team. Another thing to consider is what happens if the captain with the criteria to select anybody goes first? Everybody will end up on that team. Once you get your captains ordered properly usually from a very specific criteria to a broader criteria to an all-encompassing criteria, you’ll end up with good teams. Some criteria might be similar in scope such as the short hair vs. the color blue. The important point about all this is that the team structure is based on the criteria and the order of that criteria and that you can change this at any time. Maybe halfway through the selection process, you notice a team getting large enough and decide to remove that captain from the lineup. Or you could always add a new captain. The choice is yours. What’s this have to do with the chain or responsibility? I’ll explain that right after this message from our sponsor. ( Message from Sponsor ) In the adventure game that I’ve used for examples some attacks will likely b