Using a Strategy and Factory Pattern with Dependency Injection

Question

I am working on a side project to better understand Inversion of Control and Dependency Injection and different design patterns.

I am wondering if there are best practices to using DI with the factory and strategy patterns?

My challenge comes about when a strategy (built from a factory) requires different parameters for each possible constructor and implementation. As a result I find myself declaring all possible interfaces in the service entry point, and passing them down through the application. As a result, the entry point must be changed for new and various strategy class implementations.

I have put together a paired down example for illustration purposes below. My stack for this project is .NET 4.5/C# and Unity for IoC/DI.

In this example application, I have added a default Program class that is responsible for accepting a fictitious order, and depending on the order properties and the shipping provider selected, calculating the shipping cost. There are different calculations for UPS, DHL, and Fedex, and each implemnentation may or may not rely on additional services (to hit a database, api, etc).

public class Order {     public string ShippingMethod { get; set; }     public int OrderTotal { get; set; }     public int OrderWeight { get; set; }     public int OrderZipCode { get; set; } } 

Fictitious program or service to calculate shipping cost

public class Program {     // register the interfaces with DI container in a separate config class (Unity in this case)     private readonly IShippingStrategyFactory _shippingStrategyFactory;      public Program(IShippingStrategyFactory shippingStrategyFactory)     {         _shippingStrategyFactory = shippingStrategyFactory;     }      public int DoTheWork(Order order)     {         // assign properties just as an example         order.ShippingMethod = "Fedex";         order.OrderTotal = 90;         order.OrderWeight = 12;         order.OrderZipCode = 98109;          IShippingStrategy shippingStrategy = _shippingStrategyFactory.GetShippingStrategy(order);         int shippingCost = shippingStrategy.CalculateShippingCost(order);          return shippingCost;     } }  // Unity DI Setup public class UnityConfig {     var container = new UnityContainer();     container.RegisterType<IShippingStrategyFactory, ShippingStrategyFactory>();     // also register  IWeightMappingService and IZipCodePriceCalculator with implementations }  public interface IShippingStrategyFactory {     IShippingStrategy GetShippingStrategy(Order order); }  public class ShippingStrategyFactory : IShippingStrategyFactory {     public IShippingStrategy GetShippingStrategy(Order order)     {         switch (order.ShippingMethod)         {             case "UPS":                 return new UPSShippingStrategy();              // The issue is that some strategies require additional parameters for the constructor             // SHould the be resolved at the entry point (the Program class) and passed down?             case "DHL":                 return new DHLShippingStrategy();              case "Fedex":                 return new FedexShippingStrategy();              default:                 throw new NotImplementedException();          }     } } 

Now for the Strategy interface and implementations. UPS is an easy calculation, while DHL and Fedex may require different services (and different constructor parameters).

public interface IShippingStrategy {     int CalculateShippingCost(Order order); }  public class UPSShippingStrategy : IShippingStrategy() {     public int CalculateShippingCost(Order order)     {         if (order.OrderWeight < 5)             return 10; // flat rate of $10 for packages under 5 lbs         else             return 20; // flat rate of $20     } }  public class DHLShippingStrategy : IShippingStrategy() {     private readonly IWeightMappingService _weightMappingService;      public DHLShippingStrategy(IWeightMappingService weightMappingService)     {         _weightMappingService = weightMappingService;     }      public int CalculateShippingCost(Order order)     {         // some sort of database call needed to lookup pricing table and weight mappings         return _weightMappingService.DeterminePrice(order);     } }  public class FedexShippingStrategy : IShippingStrategy() {     private readonly IZipCodePriceCalculator _zipCodePriceCalculator;      public FedexShippingStrategy(IZipCodePriceCalculator zipCodePriceCalculator)     {         _zipCodePriceCalculator = zipCodePriceCalculator;     }      public int CalculateShippingCost(Order order)     {         // some sort of dynamic pricing based on zipcode         // api call to a Fedex service to return dynamic price         return _zipCodePriceService.CacluateShippingCost(order.OrderZipCode);     } } 

The issue with the above is that each strategy requires additional and different services to perform the 'CalculateShippingCost' method. Do these interfaces/implementations need to be registered with the entry point (the Program class) and passed down through the constructors?

Are there other patterns that would be a better fit to accomplish the above scenario? Maybe something that Unity could handle specifically (https://msdn.microsoft.com/en-us/library/dn178463(v=pandp.30).aspx)?

I greatly appreciate any help or a nudge in the right direction.

Thanks, Andy

Answer 1

There are a few ways of doing this, but the way I prefer is to inject a list of available strategies into your factory, and then filtering them to return the one(s) you're interested in.

Working with your example, I'd modify IShippingStrategy to add a new property:

public interface IShippingStrategy {     int CalculateShippingCost(Order order);     string SupportedShippingMethod { get; } } 

Then I'd implement the factory like so:

public class ShippingStrategyFactory : IShippingStrategyFactory {     private readonly IEnumerable<IShippingStrategy> availableStrategies;      public ShippingStrategyFactory(IEnumerable<IShippingStrategy> availableStrategies)     {         this.availableStrategies = availableStrategies;     }      public IShippingStrategy GetShippingStrategy(Order order)     {         var supportedStrategy = availableStrategies                 .FirstOrDefault(x => x.SupportedShippingMethod == order.ShippingMethod);         if (supportedStrategy == null)         {             throw new InvalidOperationException($"No supported strategy found for shipping method '{order.ShippingMethod}'.");         }          return supportedStrategy;     } } 

The main reason I like using it this way is that I never have to come back and modify the factory. If ever I have to implement a new strategy, the factory doesn't have to be changed. If you're using auto-registration with your container, you don't even have to register the new strategy either, so it's simply a case of allowing you to spend more time writing new code.