CODEWITHSUNDEEP
inversion-of-controlunity-containerfactory-pattern
Ryan Langton
Ryan Langton

Reputation: 6160

IoC for a list of named objects

I'm looking for advice on this problem and whether service locator and class naming conventions are an ok solution (I tend to avoid these anti-patterns), and potential performance ramifications.

An app has a collection of objects implementing the same interface, distinguished by name. For example:

 public interface IDog  {
      void Bark();
 }

 public class Pug: IDog {
      public void Bark() {
         // Pug bark implementation
      }
 }

 public class Beagle: IDog {
      public void Bark() {
         // Beagle bark implementation
      }
 }

In the code, when you need an IDog, you only know a string name that is passed to you, for example "Pug" or "Beagle". In this case the string may contain special characters (example: <breed:pug />) There are a few proposed solutions that have come about:

  1. Using reflection, find the implementation needed where the string name == implementation name.
  2. Add an addribute to each class, use reflection where string name == attribute property. Ex [DogBreed("Pug")]

  3. Add a Breed property to the IDog interface. Inject a IList into a factory class, and have it retrieve the matching dog. Ex.

    Private IList _dogs; Public DogFactory(IList<IDog> dogs) { _dogs = dogs; } Public IDog GetDog(string dogBreed) { return _dogs.First(x => x.Breed == dogBreed); }

1 and 2 use service locator. 1 uses an implied naming convention that you will only know by seeing the reflection code. 3 the concern is that all of the objects will be built in memory even though you only need a single implementation.

I personally have leaned towards #3 in the past. Object creation should be cheap. However, this is a legacy web app and objects down the chain may have heavy initialization cost. This application uses Unity for IoC.

Upvotes: 3

Views: 163

Answers (1)

Mark Seemann
Mark Seemann

Reputation: 233307

Option 1.

This option sounds like the Partial Type Name Role Hint idiom. If you inject the list of candidates and find the appropriate Strategy among those candidates, it's just plain old Constructor Injection, and has nothing to do with Service Locator (which is a good thing).

Option 2.

This option sounds like the Metadata Role Hint idiom. Again, if you inject the list of candidates via the constructor, Service Locator is nowhere to be seen.

Option 3.

This options sounds like a variation of the Role Interface Role Hint idiom. Still supports use of good old Constructor Injection.

Personally, I tend to favour Partial Type Name Role Hint because this design doesn't impact the implementation of any business logic. All the selection logic becomes a pure infrastructure concern, and can be defined independently of the implementations and clients.

When it comes to the cost of composing the relevant object graphs, there are ways to address any issues in clean ways.

Upvotes: 3

Related Questions