who should instantiate and assign runtime strategy implementations?

Question

When implementing the strategy pattern, how do you determine which class is responsible for:

1. Selecting the specific concrete strategy implementation to pass to the Context class (assuming that the selection is based on some complex business logic and not a static flag)

2. Instantiating the aforementioned concrete implementation and actually injecting it into the Context class

It feels like there ought to be some objective guidance out there that covers this. I've done some reading on various OOP patterns (i.e. GRASP and SOLID) but I still don't have a lot of clarity around this particular question.

Thanks for your time.

Answer 1

This is very close to the issues I was having with a DI container. Have a look here, Mark Seemann has provided a great answer.

Answer 2

If you are trying to address a particular situation, you are looking for the abstract factory pattern. A factory determines how to instantiate a family of types based on runtime information.

If you are wondering how to address this situation in the abstract, you are looking for an Inversion of Control container, which manages the organization and fulfillment of dependencies. The registration of the strategy would include the conditional logic.

Answer 3

That determination is context-specific, just like everything else with Desing Patterns. Quoting from the GoF book (italics mine):

What is a Design Pattern?

Christopher Alexander says, "Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice" [AIS+77, page x]. Even though Alexander was talking about patterns in buildings and towns, what he says is true about object-oriented design patterns. Our solutions are expressed in terms of objects and interfaces instead of walls and doors, but at the core of both kinds of patterns is a solution to a problem in a context.

...

The solution describes the elements that make up the design, their relationships, responsibilities, and collaborations. The solution doesn't describe a particular concrete design or implementation, because a pattern is like a template that can be applied in many different situations. Instead, the pattern provides an abstract description of a design problem and how a general arrangement of elements (classes and objects in our case) solves it.