Academic Integrity: tutoring, explanations, and feedback — we don’t complete graded work or submit on a student’s behalf.

Lately I\'ve used this technique a few times, and I\'m trying to figure out if i

ID: 642284 • Letter: L

Question

Lately I've used this technique a few times, and I'm trying to figure out if it has a name, if it's one of the patterns, etc.

In complicated situations where I might normally have a number of giant select case statements, I've been experimenting with a more plugin-style approach.

I create an interface, let's called it IProblemHandler, and maybe that interface exposes a property enumerating the kinds of problems it can handle (IProblemHandler.HandledProblems), or even better, maybe the problem it handles is embedded in the class name - convention over configuration.

Then, instead of a select case statement, I call some code that reflects through all the classes in a certain assembly and pulls the ones that implement the interface, then it determines which one is appropriate for the problem at hand, instantiates it, and solves the problem.

In the past I've used it as a plugin architecture, but it's turning out to be really useful as a way to handle certain kinds of complexity. It seems like maybe this is the domain of IoC containers and so on. I know the managed extensibility framework does some of this stuff.

So... Do you know of a name for this sort of thing?

Explanation / Answer

I don't think this is a design pattern as such (at least not by itself). To me it sounds like you're using reflection to simplify registration when using an IoC container.

For example, if you have multiple problem solvers for your problems and you have something like this:

public interface ISolveProblems<T> where T: Problem
{
void Solve(T problem);
}

public abstract class Problem
{
}

public class BigProblem : Problem
{
}

public class BigProblemSolver : ISolveProblems<BigProblem>
{
public void Solve(BigProblem problem)
{
// do whatever
}
}

public class SomeOtherBigProblemSolver : ISolveProblems<BigProblem>
{
public void Solve(BigProblem problem)
{
// do whatever
}
}
Then registering everything by hand is a pain once you have hundreds of the things, but using reflection you can wire it all up really easily on application startup. This isn't chain of responsibility, although you can set that up with this technique as well.

I'm not sure if this has a specific name, but in general I think having things set up in a way that allows this means you have a 'pluggable architecture'.