Pattern where only one handler of many should act based on specialization

Question

I'm trying to rewrite some code to break some coupling issues and make it easier to modify in the future.

Right now, I have a static factory method in a base class that, depending on the situation, picks an appropriate implementation. The decision is based on degrees of specialization:

While types A and B both can handle this, B was designed specifically for this situation and is the correct choice.

The base class is therefore intimately coupled with all implementations and this method must be rewritten when new specialized implementations are created.

I'm thinking about using the Chain of Responsibility pattern to break this coupling. However, I cannot see a way of ensuring that the most qualified implementation executes. If I give it over to the implementations to make this determination, I cannot guarantee they will be queried in order of specialization without encountering the same coupling issues.

Are there any patterns or methods for handling situations like this? (My best guess would hinder deployment; I'll keep it in my back pocket lest everybody say "yeah, that's the only way to do it!")

Answer 1

You need to create one particular implementation from the many available based on some runtime data - that sounds like the Abstract Factory pattern.

Answer 2

If you have a way to quantify how we an implementation can handle a specific situation, you could use a variation of Chain of Responsibility.

The individual implementations could provide a quantified ranking of their ability to handle a given set of inputs, and you could use this ranking to choose the "best" implementation to use.

However, this is not necessarily a great design - it provides a lot of trust to the individual implementations, and requires them to be "honest" about how well they can handle a specific situation. It's also still possible to get into a situation where multiple implementations report the same value, in which can you need to choose some means of picking.

Answer 3

If you can define some kind of proper ordering function for each case you could have each class register its self along with a type specific factory and sort based on that:

class Base;
class CaseInfo;

class TypeFactory {
 public:
  virtual Base MakeOne();

  //... Anything needed to implement Compare
}

// each derived type must inject a instance into AllTypes
dequeue<TypeFactory> AllTypes;

bool Compare(const TypeFactory&, const TypeFactory&, const CaseInfo&);
Base Best(const CaseInfo&);

The only issue I can think of is that Compare will be non-trivial. For any CaseInfo, it must uniquely select a best match. The trick will be selecting the "Anything else" bit.

Answer 4

I'm not sure Chain of Responsibility can be modeled like this. The handlers for chain of responsibility can only do 2 things. Process the request or pass it to the next handler. It doesn't know which handler is next or who's should process the request it only knows that it cannot.

Your handlers need to be more selective. If you have a handler that you want to handle IE windows and one to handle Java App then the two handlers need to be able to detect what type of window they are handling. The IE handler checks if the window is IE if not it passes it, it doesn't care if it gets handled somewhere else, it just knows that it can't handle it.

My suggestion, make specific handlers that only handle 1 window type. Make 1 generic handler. Then order the handlers so the generic handler is last. Any specialized handlers will attempt to run it first, if none are found the generic handler will process the request.

If you really wanted to do what your suggesting then you can make multiple passes to the handlers. Pass 1 only very specialized windows get caught. Pass 2 less specialized windows get caught. Etc etc until you're tired of making passes. However, for me... I say, don't try to do to much with 1 handler. If each handler is responsible for 1 window then the order doesn't matter, they will always handle the correct window type. Any unknown windows will be caught by the generic handler.

Answer 5

The solution might a hybrid of chain of responsibility and a visitor pattern. the visitor can abstract a few of the common behavioral aspects.