SOLID principles in .NET revisited part 7: the Dependency Inversion Principle

Introduction

In the previous post we saw the definition of the Interface Segregation Principle. We applied it to a problematic case where a class could not fully implement the IAuthorizationService interface. We then broke up the interface into two parts so that they became more specialised. A consequence of ISP is often a large number of small, very specialised interfaces of 1 or maybe 2 methods. Large, monolithic interfaces are to be avoided as it will be more difficult to find concrete classes that can meaningfully implement all interface methods.

We’ve reached the last letter in the SOLID acronym, i.e. ‘D’ which stands for the Dependency Inversion Principle.

Read more of this post

SOLID design principles in .NET: the Dependency Inversion Principle Part 5, Hello World revisited

Introduction

I realise that the previous post should have been the last one on the Dependency Inversion Principle but I decided to add one more, albeit a short one. It can be beneficial to look at one more example where we take a very easy starting point and expand it according to the guidelines we’ve looked at in this series.

The main source in the series on Dependency Injection is based on the work of Mark Seemann and his great book on DI.

Demo

The starting point of the exercise is the good old one-liner Hello World programme:

static void Main(string[] args)
{
	Console.WriteLine("Hello world");
}

Now that we’re fluent in DIP and SOLID we can immediately see a couple of flaws with this solution:

  • We can only write to the Console – if we want to write to a file then we’ll have to modify Main
  • We can only print Hello world to the console – we have to manually overwrite this bit of code if we want to print something else
  • We cannot easily extend this application in a sense that it lacks any seams that we discussed before – what if we want to add logging or security checks?

Let’s try to rectify these shortcomings. We’ll tackle the problem of message printing first. The Adapter pattern solves the issue by abstracting away the Print operation in an interface:

public interface ITextWriter
{
	void WriteText(string text);
}

We can then implement the Console-based solution as follows:

public class ConsoleTextWriter : ITextWriter
{
	public void WriteText(string text)
	{
		Console.WriteLine(text);
	}
}

Next let’s find a solution for collecting what the text writer needs to output. We’ll take the same approach and follow the adapter pattern:

public interface IMessageCollector
{
	string CollectMessageFromUser();
}

…with the corresponding Console-based implementation looking like this:

public class ConsoleMessageCollector : IMessageCollector
{
	public string CollectMessageFromUser()
	{
		Console.Write("Type your message to the world: ");
		return Console.ReadLine();
	}
}

These loose dependencies must be injected into another object, let’s call it PublicMessage:

public class PublicMessage
{
	private readonly IMessageCollector _messageCollector;
	private readonly ITextWriter _textWriter;

	public PublicMessage(IMessageCollector messageCollector, ITextWriter textWriter)
	{
		if (messageCollector == null) throw new ArgumentNullException("Message collector");
		if (textWriter == null) throw new ArgumentNullException("Text writer");
		_messageCollector = messageCollector;
		_textWriter = textWriter;
	}

	public void Shout()
	{
		string message = _messageCollector.CollectMessageFromUser();
		_textWriter.WriteText(message);
	}
}

You’ll realise some of the most basic techniques we’ve looked at in this series: constructor injection, guard clause, readonly private backing fields.

We can use these objects from Main as follows:

static void Main(string[] args)
{
	IMessageCollector messageCollector = new ConsoleMessageCollector();
	ITextWriter textWriter = new ConsoleTextWriter();
	PublicMessage publicMessage = new PublicMessage(messageCollector, textWriter);
	publicMessage.Shout();

	Console.ReadKey();
}

Now we’re free to inject any implementation of those interfaces: read from a database and print to file; read from a file and print to an email; read from the console and print to some web service. The PublicMessage class won’t care, it’s oblivious of the concrete implementations.

This solution is a lot more extensible. We can use the decorator pattern to add functionality to the text writer. Let’s say we want to add logging to the text writer through the following interface:

public interface ILogger
{
	void Log();
}

We can have some default implementation:

public class DefaultLogger : ILogger
{
	public void Log()
	{
		//implementation ignored
	}
}

We can wrap the text printing functionality within logging as follows:

public class LogWriter : ITextWriter
{
	private readonly ILogger _logger;
	private readonly ITextWriter _textWriter;

	public LogWriter(ILogger logger, ITextWriter textWriter)
	{
		if (logger == null) throw new ArgumentNullException("Logger");
		if (textWriter == null) throw new ArgumentNullException("TextWriter");
		_logger = logger;
		_textWriter = textWriter;
	}

	public void WriteText(string text)
	{
		_logger.Log();
		_textWriter.WriteText(text);
	}
}

In Main you can have the following:

static void Main(string[] args)
{
	IMessageCollector messageCollector = new ConsoleMessageCollector();
	ITextWriter textWriter = new LogWriter(new DefaultLogger(), new ConsoleTextWriter());
	PublicMessage publicMessage = new PublicMessage(messageCollector, textWriter);
	publicMessage.Shout();

	Console.ReadKey();
}

Notice that we didn’t have to do anything to PublicMessage. We passed in the interface dependencies as before and now we have the logging function included in message writing. Also, note that Main is tightly coupled to a range of objects, but it is acceptable in this case. We construct our objects in the entry point of the application, i.e. the composition root which is the correct place to do that. We don’t new up any dependencies within PublicMessage.

This was of course a very contrived example. We expanded the original code to a lot more complex solution with a lot higher overhead. However, real life applications, especially enterprise ones are infinitely more complicated where requirements change a lot. Customers are usually not sure what they want and wish to include new and updated features in the middle of the project. It’s vital for you as a programmer to be able to react quickly. Enabling loose coupling like that will make your life easier by not having to change several seemingly unrelated parts of your code.

View the list of posts on Architecture and Patterns here.

SOLID design principles in .NET: the Dependency Inversion Principle Part 4, Interception and conclusions

Introduction

I briefly mentioned the concept of Interception in the this post. It is a technique that can help you implement cross-cutting concerns such as logging, tracing, caching and other similar activities. Cross-cutting concerns include actions that are not strictly related to a specific domain but can potentially be called from many different objects. E.g. you may want to cache certain method results pretty much anywhere in your application so potentially you’ll need an ICacheService dependency in many places. In the post mentioned above I went through a possible DI pattern – ambient context – to implement such actions with all its pitfalls.

If you’re completely new to these concepts make sure you read through all the previous posts on DI in this series. I won’t repeat what was already explained before.

The idea behind Interception is quite simple. When a consumer calls a service you may wish to intercept that call and execute some action before and/or after the actual service is invoked.

It happens occasionally that I do the shopping on my way home from work. This is a real life example of interception: the true purpose of my action is to get home but I “intercept” that action with another one, namely buying some food. I can also do the shopping when I pick up my daughter from the kindergarten or when I want to go for a walk. So I intercept the main actions PickUpFromKindergarten() and GoForAWalk() with the shopping action because it is convenient to do so. The Shopping action can be injected into several other actions so in this case it may be considered as a Cross-Cutting Concern. Of course the shopping activity can be performed in itself as the main action, just like you can call a CacheService directly to cache something, in which case it too can be considered as the main action.

The main source in the series on Dependency Injection is based on the work of Mark Seemann and his great book on DI.

The problem

Say you have a service that looks up an object with an ID:

public interface IProductService
{
	Product GetProduct(int productId);
}
public class DefaultProductService : IProductService
{
	public Product GetProduct(int productId)
	{
		return new Product();
	}
}

Say you don’t want to look up this product every time so you decide to cache the result for 10 minutes.

Possible solutions

Total lack of DI

The first “solution” is to directly implement caching within the GetProduct method. Here I’m using the ObjectCache object located in the System.Runtime.Caching namespace:

public Product GetProduct(int productId)
{
	ObjectCache cache = MemoryCache.Default;
	string key = "product|" + productId;
	Product p = null;
	if (cache.Contains(key))
	{
		p = (Product)cache[key];
	}
	else
	{
		p = new Product();
		CacheItemPolicy policy = new CacheItemPolicy();
		DateTimeOffset dof = DateTimeOffset.Now.AddMinutes(10);
		policy.AbsoluteExpiration = dof;
		cache.Add(key, p, policy);
	}
	return p;
}

We check the cache using the cache key and retrieve the Product object if it’s available. Otherwise we simulate a database lookup and put the Product object in the cache with an absolute expiration of 10 minutes.

If you’ve read through the posts on DI and SOLID then you should know that this type of code has numerous pitfalls:

  • It is tightly coupled to the ObjectCache class
  • You cannot easily specify a different caching strategy – if you want to increase the caching time to 20 minutes then you’ll have to come back here and modify the method
  • The method signature does not tell anything to the caller about caching, so it violates the idea of an Intention Revealing Interface mentioned before
  • Therefore the caller will need to intimately know the internals of the GetProduct method
  • The method is difficult to test as it’s impossible to abstract away the caching logic. The test result will depend on the caching mechanism within the code so it will be inconclusive

Nevertheless you have probably encountered this style of coding quite often. There is nothing stopping you from writing code like that. It’s quick, it’s dirty, but it certainly works.

As an attempt to remedy the situation you can factor out the caching logic to a service:

public class SystemRuntimeCacheStorage
{
	public void Remove(string key)
	{
		ObjectCache cache = MemoryCache.Default;
		cache.Remove(key);
	}

	public void Store(string key, object data)
	{
		ObjectCache cache = MemoryCache.Default;
		cache.Add(key, data, null);
	}

	public void Store(string key, object data, DateTime absoluteExpiration, TimeSpan slidingExpiration)
	{
		ObjectCache cache = MemoryCache.Default;
		var policy = new CacheItemPolicy
		{
			AbsoluteExpiration = absoluteExpiration,
			SlidingExpiration = slidingExpiration
		};

		if (cache.Contains(key))
		{
			cache.Remove(key);
		}
		cache.Add(key, data, policy);
	}

	public T Retrieve<T>(string key)
	{
		ObjectCache cache = MemoryCache.Default;
		return cache.Contains(key) ? (T)cache[key] : default(T);
	}
}

This is a generic class to store, remove and retrieve objects of type T. As the next step you want to call this service from the DefaultProductService class as follows:

public class DefaultProductService : IProductService
{
	private SystemRuntimeCacheStorage _cacheStorage;

	public DefaultProductService()
	{
		_cacheStorage = new SystemRuntimeCacheStorage();
	}

	public Product GetProduct(int productId)
	{
		string key = "product|" + productId;
		Product p = _cacheStorage.Retrieve<Product>(key);
		if (p == null)
		{
        		p = new Product();
			_cacheStorage.Store(key, p);
		}
		return p;
	}
}

We’ve seen a similar example in the previous post where the consuming class constructs its own dependency. This “solution” has the same errors as the one above – it’s only the stacktrace that has changed. You’ll get the same faulty design with a factory as well. However, this was a step towards a loosely coupled solution.

Dependency injection

As you know by now abstractions are the way to go to reach loose coupling. We can factor out the caching logic into an interface:

public interface ICacheStorage
{
	void Remove(string key);
	void Store(string key, object data);
	void Store(string key, object data, DateTime absoluteExpiration, TimeSpan slidingExpiration);
	T Retrieve<T>(string key);
}

Then using constructor injection we can inject the caching mechanism as follows:

public class DefaultProductService : IProductService
{
	private readonly ICacheStorage _cacheStorage;

	public DefaultProductService(ICacheStorage cacheStorage)
	{
		_cacheStorage = cacheStorage;
	}

	public Product GetProduct(int productId)
	{
		string key = "product|" + productId;
		Product p = _cacheStorage.Retrieve<Product>(key);
		if (p == null)
		{
			p = new Product();
			_cacheStorage.Store(key, p);
		}
		return p;
	}
}

Now we can inject any type of concrete caching solution which implements the ICacheStorage interface. As far as tests are concerned you can inject an empty caching solution using the Null object pattern so that the test can concentrate on the true logic of the GetProduct method.

This is certainly a loosely coupled solution but you may need to inject similar interfaces to a potentially large number of services:

public ProductService(ICacheStorage cacheStorage, ILoggingService loggingService, IPerformanceService performanceService)
public CustomerService(ICacheStorage cacheStorage, ILoggingService loggingService, IPerformanceService performanceService)
public OrderService(ICacheStorage cacheStorage, ILoggingService loggingService, IPerformanceService performanceService)

These services will permeate your class structure. Also, you may create a base service for all services like this:

public ServiceBase(ICacheStorage cacheStorage, ILoggingService loggingService, IPerformanceService performanceService)

If all services must inherit this base class then they will start their lives with 3 abstract dependencies that they may not even need. Also, these dependencies don’t represent the true purpose of the services, they are only “sidekicks”.

Ambient context

For a discussion on this type of DI and when and why (not) to use it consult this post.

Interception using the Decorator pattern

The Decorator design pattern can be used as a do-it-yourself interception. The product service class can be reduced to its true purpose:

public class DefaultProductService : IProductService
	{		
		public Product GetProduct(int productId)
		{
			return new Product();
		}
	}

A cached product service might look as follows:

public class CachedProductService : IProductService
{
	private readonly IProductService _innerProductService;
	private readonly ICacheStorage _cacheStorage;

	public CachedProductService(IProductService innerProductService, ICacheStorage cacheStorage)
	{
		if (innerProductService == null) throw new ArgumentNullException("ProductService");
		if (cacheStorage == null) throw new ArgumentNullException("CacheStorage");
		_cacheStorage = cacheStorage;
		_innerProductService = innerProductService;
	}

	public Product GetProduct(int productId)
	{
		string key = "Product|" + productId;
		Product p = _cacheStorage.Retrieve<Product>(key);
		if (p == null)
		{
			p = _innerProductService.GetProduct(productId);
			_cacheStorage.Store(key, p);
		}

		return p;
	}
}

The cached product service itself implements IProductService and accepts another IProductService in its constructor. The injected product service will be used to retrieve the product in case the injected cache service cannot find it.

The consumer can actively use the cached implementation of the IProductService in place of the DefaultProductService class to deliberately call for caching. Here the call to retrieve a product is intercepted by caching. The cached service can concentrate on its task using the injected ICacheStorage object and delegates the actual product retrieval to the injected IProductService class.

You can imagine that it’s possible to write a logging decorator, a performance decorator etc., i.e. a decorator for any type of cross-cutting concern. You can even decorate the decorator to include logging AND caching. Here you see several applications of SOLID. You keep the product service clean so that it adheres to the Single Responsibility Principle. You extend its functionality through the cached product service decorator which is an application of the Open-Closed principle. And obviously injecting the dependencies through abstractions is an example of the Dependency Inversion Principle.

The Decorator is a well-tested pattern to implement interception in a highly flexible object-oriented way. You can implement a lot of decorators for different purposes and you will adhere to SOLID pretty well. However, imagine that in a large business application with hundreds of domains and hundreds of services you may potentially have to write hundreds of decorators. As each decorator executes one thing only to adhere to SRP you may need to implement 3-4 decorators for each service.

That’s a lot of code to write… This is actually a practical limitation of solely using this pattern in a large application to achieve interception: it’s extremely repetitive and time consuming.

Aspect oriented programming (AOP)

The idea behind AOP is strongly related to attributes in .NET. An example of an attribute in .NET is the following:

[PrincipalPermission(SecurityAction.Demand, Role = "Administrator")]
protected void Page_Load(object sender, EventArgs e)
{
}

This is also an example of interception. The PrincipalPermission attribute checks the role of the current principal before the decorated method can continue. In this case the ASP.NET page won’t load unless the principal has the Administrator role. I.e. the call to Page_Load is intercepted by this Security attribute.

The decorator pattern we saw above is an example of imperative coding. The attributes are an example of declarative interception. Applying attributes to declare aspects is a common technique in AOP. Imagine that instead of writing all those decorators by hand you could simply decorate your objects as follows:

[Cached]
[Logged]
[PerformanceChecked]
public class DefaultProductService : IProductService
{		
	public Product GetProduct(int productId)
	{
		return new Product();
	}
}

It looks attractive, right? Well, let’s see.

The PrincipalPermission attribute is special as it’s built into the .NET base class library (BCL) along with some other attributes. .NET understands this attribute and knows how to act upon it. However, there are no built-in attributes for caching and other cross-cutting concerns. So you’d need to implement your own aspects. That’s not too difficult; your custom attribute will need to derive from the System.Attribute base class. You can then decorate your classes with your custom attribute but .NET won’t understand how to act upon it. The code behind your implemented attribute won’t run just like that.

There are commercial products, like PostSharp, that enable you to write attributes that are acted upon. PostSharp carries out its job by modifying your code in the post-compilation step. The “normal” compilation runs first, e.g. by csc.exe and then PostSharp adds its post-compilation step by taking the code behind your custom attribute(s) and injecting it into the code compiled by csc.exe in the correct places.

This sounds enticing. At least it sounded to me like heaven when we tested AOP with PostSharp: we wanted to measure the execution time and save several values about the caller of some very important methods of a service. So we implemented our custom attributes and very extremely proud of ourselves. Well, until someone else on the team started using PostSharp in his own assembly. When I referenced his project in mine I suddenly kept getting these funny notices that I have to activate my PostSharp account… So what’s wrong with those aspects?

  • The code you write will be different from what will be executed as new code will be injected into the compiled one in the post-compilation step. This may be tricky in a debugging session
  • The vendors will be happy to provide helper tools for debugging which may or may not be included in the base price and push you towards an anti-pattern where you depend on certain external vendors – also a form of tight coupling
  • All attributes must have default parameterless constructors – it’s not easy to consume dependencies from within an attribute. Your best bet is using ambient context – or abandon DI and go with default implementations of the dependencies
  • It can be difficult to fine-grain the rules when to apply an aspect. You may want to go with a convention-based applicability such as “apply the aspect on all objects whose name ends with ‘_log'”
  • The aspect itself is not an abstraction; it’s not straightforward to inject different implementations of an aspect – therefore if you decide to go with the System.Runtime.Cache in your attribute implementation then you cannot change your mind afterwards. You cannot implement a factory or any other mechanism to inject a certain aspect in place of some abstract aspect as there’s no such thing

This last point is probably the most serious one. It pulls you towards the dreaded tight-coupling scenario where you cannot easily redistribute a class or a module due to the concrete dependency introduced by an aspect. If you consume such an external library, like in the example I gave you, then you’re stuck with one implementation – and you better make sure you have access to the correct credentials to use that unwanted dependency…

Dynamic interception with a DI container

We briefly mentioned DI containers, or IoC containers in this series. You may be familiar with some of them, such as StructureMap and CastleWindsor. I won’t get into any details regarding those tools. There are numerous tutorials available on the net to get you started. As you get more and more exposed to SOLID in your projects then eventually you’ll most likely become familiar with at least one of them.

Dynamic interception makes use of the ability of .NET to dynamically emit types. Some DI containers enable you to automate the generation of decorators to be emitted straight into a running process.

This approach is fully object-oriented and helps you avoid the shortcomings of AOP attributes listed above. You can register your own decorators with the IoC container, you don’t need to rely on a default one.

If you are new to DI containers then make sure you understand the basics before you go down the dynamic interception route. I won’t show you any code here on how to implement this technique as it depends on the type of IoC container of your choosing. The key steps as far as CastleWindsor is concerned are as follows:

  • Implement the IInterceptor interface for your decorator
  • Register the interceptor with the container
  • Activate the interceptor by implementing the IModelInterceptorsSelector interface – this is the step where you declare when and where the interceptors will be invoked
  • Register the class that implements the IModelInterceptorsSelector interface with the container

Carefully following these steps will ensure that you can implement dynamic interception without the need for attributes. Note that not all IoC containers come with the feature of dynamic interception.

Conclusions

In this mini-series on DI within the series about SOLID I hope to have explained the basics of the Dependency Inversion Principle. This last constituent of SOLID is probably the one that has caused the most controversy and misunderstanding of the 5. Ask 10 developers on the purposes of DIP and you’ll get 11 different answers. You may absolutely have come across ideas in these posts that you disagree with – feel free to comment in that case.

However, I think there are several myths and misunderstandings about DI and DIP that were successfully dismissed:

  • DI is the same as IoC containers: no, IoC containers can automate DI but you can by any means apply DI in your code without a tool like that
  • DI can be solved with factories: look at the post on DI anti-patterns and you’ll laugh at this idea
  • DI requires an IoC containers: see the first point, this is absolutely false
  • DI is only necessary if you want to enable unit testing: no, DI has several advantages as we saw, effective unit testing being only one of them
  • Interception is best done with AOP: no, see above
  • Using an IoC container will automatically result in DI: no, you have to prepare your code according to the DI patterns otherwise an IoC container will have nothing to inject

View the list of posts on Architecture and Patterns here.

SOLID design principles in .NET: the Dependency Inversion Principle Part 3, DI anti-patterns

In the previous post we discussed the various techniques how to implement Dependency Injection. Now it’s time to show how NOT to do DI. Therefore we’ll look at a couple of anti-patterns in this post.

The main source in the series on Dependency Injection is based on the work of Mark Seemann and his great book on DI.

Lack of DI

The most obvious DI anti-patterns is the total absence of it where the class controls it dependencies. It is the most common anti-pattern in DI to see code like this:

public class ProductService
{
	private ProductRepository _productRepository;

	public ProductService()
	{
		_productRepository = new ProductRepository();
	}
}

Here the consumer class, i.e. ProductService, creates an instance of the ProductRepository class with the ‘new’ keyword. Thereby it directly controls the lifetime of the dependency. There’s no attempt to introduce an abstraction and the client has no way of introducing another type – implementation – for the dependency.

.NET languages, and certainly other similar platforms as well, make this extremely easy for the programmer. There is no automatic SOLID checking in Visual Studio, and why would there be such a mechanism? We want to give as much freedom to the programmer as possible, so they can pick – or even mix – C#, VB, F#, C++ etc., write in an object-oriented way or follow some other style, so there’s a high degree of control given to them within the framework. So it feels natural to new up objects as much as we like: if I need something I’ll need to go and get it. If the ProductService needs a product repository then it will need to fetch one. So even experienced programmers who know SOLID and DI inside out can fall into this trap from time to time, simply because it’s easy and programming against abstractions means more work and a higher degree of complexity.

The first step towards salvation may be to declare the private field as an abstract type and mark it as readonly:

public class ProductService
{
	private readonly IProductRepository _productRepository;

	public ProductService()
	{
		_productRepository = new ProductRepository();
	}
}

However, not much is gained here yet, as at runtime _productRepository will always be a new ProductRepository.

A common, but very wrong way of trying to resolve the dependency is by using some Factory. Factories are an extremely popular pattern and they seem to be the solution to just about anything – besides copy/paste of course. I’m half expecting Bruce Willis to save the world in Die Hard 27 by applying the static factory pattern. So no wonder people are trying to solve DI with it too. You can see from the post on factories that they come in 3 forms: abstract, static and concrete.

The “solution” with the concrete factory may look like this:

public class ProductRepositoryFactory
{
	public ProductRepository Create()
	{
		return new ProductRepository();
	}
}
public ProductService()
{
	ProductRepositoryFactory factory = new ProductRepositoryFactory();
	_productRepository = factory.Create();
}

Great, we’re now depending directly on ProductRepositoryFactory and ProductRepository is still hard-coded within the factory. So instead of just one hard dependency we now have two, well done!

What about a static factory?

public class ProductRepositoryFactory
{
	public static ProductRepository Create()
	{
		return new ProductRepository();
	}
}
public ProductService()
{
	_productRepository = ProductRepositoryFactory.Create();
}

We’ve got rid of the ‘new’, yaaay! Well, no, if you recall from the introduction using static methods still creates a hard dependency, so ProductService still depends directly on ProductRepositoryFactory and indirectly on ProductRepository.

To make matters worse the static factory can be misused to produce a sense of freedom to the client to control the type of dependency as follows:

public class ProductRepositoryFactory
{
	public static IProductRepository Create(string repositoryTypeDescription)
	{
		switch (repositoryTypeDescription)
		{
			case "default":
				return new ProductRepository();
			case "test":
				return new TestProductRepository();
			default:
				throw new NotImplementedException();
		}
	}
}
public ProductService()
{
	_productRepository = ProductRepositoryFactory.Create("default");
}

Oh, brother, this is a real mess. ProductService still depends on the ProductRespositoryFactory class, so we haven’t eliminated that. It is now indirectly dependent on the two concrete repo types returned by factory. Also, we now have magic strings flying around. If we ever introduce a third type of repository then we’ll need to revisit the factory and inform all actors that there’s a new magic string. This model is very difficult to extend. The ability to configure in code, or possibly in a config file, gives a false sense of security to the developer.

You can create a mock Product repository for a unit test scenario, extend the switch-case statement in the factory and maybe introduce a new magic string “mock” only for testing purposes. Then you can put “mock” in the Create method, recompile and run your test just for unit testing. Then you forget to put it back to “sql” or whatever and deploy the solution… Realising this you may want to overload the ProductService constructor like this:

public ProductService(string productRepoDescription)
{
	_productRepository = ProductRepositoryFactory.Create(productRepoDescription);
}

That only moves the magic string problem up the stacktrace but does nothing to solve the dependency problems outlined above.

Let’s look at an abstract factory:

public interface IProductRepositoryFactory
{
	IProductRepository Create(string repoDescription);
}

ProductRepositoryFactory can implement this interface:

public class ProductRepositoryFactory : IProductRepositoryFactory
{
	public IProductRepository Create(string repositoryTypeDescription)
	{
		switch (repositoryTypeDescription)
		{
			case "default":
				return new ProductRepository();
			case "test":
				return new TestProductRepository();
			default:
				throw new NotImplementedException();
		}
	}
}

You can use it from ProductService as follows:

private IProductRepositoryFactory _productRepositoryFactory;
private IProductRepository _productRepository;

public ProductService(string productRepoDescription)
{
	_productRepositoryFactory = new ProductRepositoryFactory();
	_productRepository = _productRepositoryFactory.Create(productRepoDescription);
}

We need to new up a ProductRepositoryFactory, so we’re back at square one. However, abstract factory is still the least harmful of the factory patterns when trying to solve DI as we can refactor this code in the following way:

private readonly IProductRepository _productRepository;

public ProductService(string productRepoDescription, IProductRepositoryFactory productRepositoryFactory)
{
	_productRepository = productRepositoryFactory.Create(productRepoDescription);
}

This is not THAT bad. We can provide any type of factory now but we still need to provide a magic string. A way of getting rid of that string would be to create specialised methods within the factory as follows:

public interface IProductRepositoryFactory
{
	IProductRepository Create(string repoDescription);
	IProductRepository CreateTestRepository();
	IProductRepository CreateSqlRepository();
	IProductRepository CreateMongoDbRepository();
}

…with ProductService using it like this:

private readonly IProductRepository _productRepository;

public ProductService(IProductRepositoryFactory productRepositoryFactory)
{
	_productRepository = productRepositoryFactory.CreateMongoDbRepository();
}

This is starting to look like proper DI. We can inject our own version of the factory and then pick the method that returns the necessary repository type. However, this is a false positive impression again. The ProductService still controls the type of repository returned by the factory. If we wanted to test the SQL repo then we have to revisit the product service – and all other services that need a repository – and select CreateSqlRepository() instead. Same goes for unit testing. You can certainly create a mock repository factory but you’ll need to make sure that the mock implementation returns mock objects for all repository types the factory returns. That breaks ISP in SOLID.

No, even in the above case the caller cannot control type of IProductRepository used within ProductRepository. You can certainly control the concrete implementation of IProductRepositoryFactory, but that’s not enough.

Conclusion: factories are great for purposes other than DI. Use one of the strategies outlined in the previous post.

Lack of DI creates tightly coupled classes where one cannot exist without the other. You cannot redistribute the ProductService class without the concrete ProductRepository so it diminishes re-usability.

Overloaded constructors

Consider the following code:

private readonly IProductRepository _productRepository;

public ProductService() : this(new ProductRepository())
{}

public ProductService(IProductRepository productRepository)
{
        _productRepository = productRepository;
}

It’s great that we have can inject an IProductRepository but what’s the default constructor doing there? It simply calls the overloaded one with a concrete implementation of the repository interface. There you are, we’ve just introduced a completely unnecessary coupling. Matters get worse if the default implementation comes from an external source such as a factory seen above:

private readonly IProductRepository _productRepository;

public ProductService() : this(new ProductRepositoryFactory().Create("sql"))
{}

public ProductService(IProductRepository productRepository)
{
	_productRepository = productRepository;
}

By now you know why factories are not suitable for solving DI so I won’t repeat myself. Even if clients always call the overloaded constructor the class still cannot exist without either the ProductRepository or the ProductRepositoryFactory class.

The solution is easy: get rid of the default constructor and force clients to provide their own implementations.

Service locator

I’ve already written a post on this available here, so I won’t repeat the whole post. In short: a Service Locator resembles a proper IoC container such as StructureMap but it introduces easily avoidable couplings between objects.

Conclusion

We’ve discussed some of the ways how not to do DI. There may certainly be more of those but these are probably the most frequent ones. The most important variant to get rid of is the lack of DI which is exacerbated by the use of factories. That’s also the easiest to spot – look for the ‘new’ keyword in conjunction with dependencies.

The use of static method and properties can also be indicators of DIP violation:

DateTime.Now.ToString();
DataAccess.SaveCustomer(customer);
ProductRepositoryFactory.Create("sql");

We’ve seen especially in the case of factories that static methods and factories only place the dependencies one step down the execution ladder. Static methods are acceptable if they don’t themselves have concrete dependencies but only use the parameters already used by the object that’s calling the static method. However, if those static methods new up other dependencies which in turn may instantiate their own dependencies then that will quickly become a tightly coupled nightmare.

View the list of posts on Architecture and Patterns here.

SOLID design principles in .NET: the Dependency Inversion Principle Part 2, DI patterns

In the previous post we went through the basics of DIP and DI. We’ll continue the discussion with the following questions: how to implement DI?

The main source in the series on Dependency Injection is based on the work of Mark Seemann and his great book on DI.

Flavours of DI

I hinted at the different forms of DI in the previous post. By far the most common form is called Constructor Injection:

public ProductService(IProductRepository productRepository)
{
	_productRepository = productRepository;
}

Constructor injection is the perfect way to ensure that the necessary dependency is always available to the class. We force the clients to supply some kind of implementation of the interface. All you need is a public constructor that accepts the dependency as a parameter. In the constructor we save the incoming concrete class for later use, i.e. assign to a private variable.

We can introduce a second level of security by introducing a guard clause:

public ProductService(IProductRepository productRepository)
{
       if (productRepository == null) throw new ArgumentNullException("ProductRepo");
	_productRepository = productRepository;
}

It is good practice to mark the private field readonly, in this case the _productRepository, as it guarantees that once the initialisation logic of the constructor has executed it cannot be modified by any other code:

private readonly IProductRepository _productRepository;

This is not required for DI to work but it protects you against mistakes such as setting the value to null someplace else in your code.

Constructor injection is a good way to document your class to the clients. The clients will see that ProductService will need an IProductRepository to perform its job. There’s no attempt to hide this fact.

When the constructor is finished then the object is guaranteed to have a valid dependency, i.e. the object is in a consistent state. The following method will not choke on a null value where _productRepository is called:

public IEnumerable<Product> GetProducts()
{
	IEnumerable<Product> productsFromDataStore = _productRepository.FindAll();	
	return productsFromDataStore;
}

We don’t need to test for null within the GetProducts method as we know it is guaranteed to be in a consistent state.

Constructor injection should be your default DI technique in case your class has a dependency and no reasonable local defaults exist. A local default is an acceptable local implementation of an abstract dependency in case none is injected by the client. We’ll talk more about this a bit later. Also, try to avoid overloaded constructors because then you’ll need to rely on those local defaults if an empty constructor is used. In addition, having just one constructor greatly simplifies the usage of automated DI containers, also called IoC containers. If you don’t know what they are, then don’t worry about them for now. They are not a prerequisite for DIP and DI and they cannot magically turn tightly coupled code into a loosely coupled one. Make sure that you first understand how to do DI without such tools.

You can read briefly about them here. In short they are ‘magic’ tools that can initialise dependencies. In the above example you can configure such a container, such as StructureMap to magically inject a MyDefaultProductRepository when it sees that an IProductRepository is needed.

The next DI type in line is called Property injection. Property injection is used when your class has a good local default for a dependency but still want to enable clients to override that default. It is also called Setter injection:

public IProductRepository ProductRepository { get; set; }

In this case you obviously cannot mark the backing field readonly.

This implementation is fragile as by default all object types are set to null so ProductRepository will also be null. You’ll need to extend the property setter as follows:

public IProductRepository ProductRepository 
{
	get
	{
		return _productRepository;
	}
	set
	{
		if (value == null) throw new ArgumentNullException("ProductRepo");
		_productRepository = value;
	}
}

We’re still not done. There’s nothing forcing the client to call this setter so the GetProducts method will throw an exception. At some point we must initialise the dependency, maybe in the constructor:

public ProductService()
{
	_productRepository = new DefaultProductRepository();
}

By now we know that initialising an object with the ‘new’ keyword increases coupling between two objects so whenever possible accept the dependency in form of an abstraction instead.

Alternatively you can take the Lazy Initialisation approach in the property getter:

public IProductRepository ProductRepository 
{
	get
	{
		if (_productRepository == null)
		{
			_productRepository = new ProductRepository();
		}
		return _productRepository;
	}
	set
	{
		if (value == null) throw new ArgumentNullException("ProductRepo");
		_productRepository = value;
	}
}

We can go even further. If you want that the client should only set the dependency once without the possibility to alter it during the object’s lifetime then the following approach can work:

public IProductRepository ProductRepository 
{
	get
	{
		if (_productRepository == null)
		{
			_productRepository = new ProductRepository();
		}
		return _productRepository;
	}
	set
	{
		if (value == null) throw new ArgumentNullException("ProductRepo");
		if (_productRepository != null) throw new InvalidOperationException("You are not allowed to set this dependency more than once.");
		_productRepository = value;
	}
}

BTW this doesn’t mean that from now on you must never again use the new keyword to initialise objects. At some point you’ll HAVE TO use it as you can’t connect the bits and pieces using abstractions only. E.g. this is invalid code:

ProductService ps = new ProductService(new IProductRepository());

No, unless you have some IoC Container in place you’ll need to go with what’s called the poor man’s dependency injection:

ProductService ps = new ProductService(new DefaultProductRepository());

Where DefaultProductRepository implements IProductRepository.

Coming back to Property injection, you can use it whenever there’s a well functioning default implementation of a dependency but you still want to let your users provide their own implementation. In other words the dependency is optional. However, this choice must be a conscious one. As there’s nothing forcing the clients to call the property setter your code shouldn’t complain if the dependency is null when it’s needed. That’s a sign saying that you need to turn to constructor injection instead. In case you don’t really need a local default then the Null Object pattern can come handy. If the local default is part of the .NET base class library then it may be an acceptable approach to use it.

As you see the last version of the property getter-setter is considerably more complex than taking the constructor injection approach. It looks easy at first, just insert a get;set; type of property but you soon notice that it’s a fragile structure.

A third way of doing DI is called method injection. It is used when we want to ensure that we can inject a different implementation every time the dependency is used:

public IEnumerable<Product> GetProducts(IProductDiscountStrategy productDiscount)
{
	IEnumerable<Product> productsFromDataStore = _productRepository.FindAll();
	foreach (Product p in productsFromDataStore)
	{
		p.AdjustPrice(productDiscount);
	}
	return productsFromDataStore;
}

Here we apply a discount strategy on each product in the iteration. The actual strategy may change a lot, it can depend on the season, the loyalty scheme, the weather, the time of the day etc. As usual you can include a guard clause:

public IEnumerable<Product> GetProducts(IProductDiscountStrategy productDiscount)
{
	if (productDiscount == null) throw new ArgumentNullException("Discount strategy");
	IEnumerable<Product> productsFromDataStore = _productRepository.FindAll();
	foreach (Product p in productsFromDataStore)
	{
		p.AdjustPrice(productDiscount);
	}
	return productsFromDataStore;
}

In this approach it’s easy to vary the concrete discount strategy every time we call the GetProducts method. If you had to inject this into the constructor then you’d need to create a new ProductService class every time you want to apply some pricing strategy. In case the method doesn’t use the injected dependency you won’t need a guard clause. This may sound strange at first; why have a dependency in the signature if it is not used in the method body? Occasionally you’re forced to implement an interface where the interface method defines the dependency – more on that in the post about the Interface Segregation Principle.

Patterns related to method injection are Factory and Strategy. Choosing the proper implementation to be injected into the GetProducts method will almost certainly depend on other inputs such as the choices the user makes on the UI. These patterns will help you solve that problem.

An example of method injection from .NET is the Contains extension method from LINQ:

bool IEnumerable<T>.Contains(T object, IEqualityComparer<T> comparer);

You can then provide your own version of the equality comparer.

The last type of DI we’ll discuss is making dependencies available through a static accessor. It is also called injection through the ambient context. It is used when implementing cross-cutting concerns.

What are cross-cutting concerns? Operations that may be performed in many unrelated classes and that are not closely related to those classes. A classic example is logging. You may want to log exceptions, performance data etc. I may want to log the time it takes the GetProducts method to return in the ProductService class. You could inject an ILogger interface to every class that needs logging but it introduces a large amount of pollution across your objects. Also, an ILogger interface attached to a constructor is not truly necessary for the dependent object to perform its real job. Logging is usually not part of the core job of services and repositories.

If you’re a web developer then you must have come across the HttpContext object at some point. It is an application of the ambient context pattern. You can always try and access that object and get hold of the current HTTP context which may or may not be available right there and then by its Current static property. You can construct your own Context object where you retrieve the current context using threads. A time provider context may look as follows:

public abstract class TimeProviderContext
{
	public static TimeProviderContext Current
	{
		get
		{
			TimeProviderContext timeProviderContext = Thread.GetData(Thread.GetNamedDataSlot("TimeProvider")) as TimeProviderContext;
			if (timeProviderContext == null)
			{
				timeProviderContext = TimeProviderContext.DefaultTimeProviderContext;
				Thread.SetData(Thread.GetNamedDataSlot("TimeProvider"), timeProviderContext);
			}
			return timeProviderContext;
		}
		set
		{
			Thread.SetData(Thread.GetNamedDataSlot("TimeProvider"), value);
		}
	}
	public static TimeProviderContext DefaultTimeProviderContext = new DotNetTimeProvider();

	public abstract DateTime GetTime { get; }
}

…where DotNetTimeProvider looks as follows:

public class DotNetTimeProvider : TimeProviderContext
{
	public override DateTime GetTime
	{
		get { return DateTime.Now; }
	}
}

The TimeProviderContext is abstract and has a static Current property to get hold of the current context. That’s the classic setup of the ambient context. Using the Thread object like that will ensure that each thread has its own context. There’s a default implementation which is the standard DateTime class from .NET. It’s important to note that the Current property must be writable so that clients can assign their own time providers by deriving from the TimeProviderContext object. This can be helpful in unit testing where ideally you want to control the time instead of waiting for some specific date. The local default makes sure that the client doesn’t get a null reference exception when calling the Current property.

For simplicity’s sake I only put a single abstract method in this class to get the date but ambient context classes can provide as many properties as you need.

You can then use this context in client classes as follows:

public DateTime TestTime()
{
	return TimeProviderContext.Current.GetTime;
}

Ambient context should be used with care. Use it only if you want to make sure that a cross-cutting concern is available anywhere throughout your application. In that case it may be futile to force objects to take on dependencies they may not need now but might do so at some point in the future:

public IProductRepository ProductRepository 
{
	get
	{
		if (_productRepository == null)
		{
			_productRepository = new ProductRepository(TimeProviderContext.Current);
		}
		return _productRepository;
	}
}

…where ProductRepository looks as follows:

public class ProductRepository : IProductRepository
{	

	public ProductRepository(TimeProviderContext timeProviderContext)
	{
		//do nothing with the time provider context right now but it may be needed later
	}

	public IEnumerable<Product> FindAll()
	{
		return new List<Product>();
	}
}

That only increases the coupling between objects and pollutes your object structure.

A disadvantage with the ambient context approach is that the consuming class carries an implicit dependency. In other words it hides from the clients that it needs a time provider in order to perform its job. If you put the TestTime() method shown above in the ProductService class then there’s no way for the client to tell just by looking at the interface that ProductService uses this dependency. Also, callers of the TestTime method will get different results depending on the actual context and it may not be transparent to them why this happens without looking at the source code.

There’s actually a technical term to describe this “openness” that Eric Evans came up with: Intention-revealing interfaces. An API should communicate what it does by its public interface alone. A class using the ambient context does exactly the opposite. Clients may know of the existence of a TimeProviderContext class but will probably not know that it is used in ProductService.

There are cross cutting concerns that only perform some task without returning an answer: logging exceptions and performance data are such cases. If you have that type of scenario then a technique called Interception is something to consider. We’ll look at interception briefly it the blog post after the next one.

Conclusion

Of the four techniques discussed your default choice should always be Constructor Injection in case there’s a dependency within your class. If the dependency varies from operation to operation then Method Injection is good candidate.

Then you can ask the question if the dependency represents a cross-cutting concern. If not and a good local default exists then you can go down the Property Injection path. Otherwise if you need some return value from the cross-cutting concern dependency and you have a good local default in case Context.Current is null then Ambient Context can help. Else if this dependency only has void methods then take a look at Interception.

When in doubt, especially if you are trying to pick a strategy between Constructor Injection and another variant then pick Constructor injection. Things can never go fatally wrong with that option.

View the list of posts on Architecture and Patterns here.

SOLID design principles in .NET: the Dependency Inversion Principle and the Dependency Injection pattern

Introduction

The Dependency Inversion Principle (DIP) helps to decouple your code by ensuring that you depend on abstractions rather than concrete implementations. Dependency Injection (DI) is an implementation of this principle. In fact DI and DIP are often used to mean the same thing. A key feature of DIP is programming to abstractions so that consuming classes can depend on those abstractions rather than low-level implementations. DI is the act of supplying all classes that a service needs rather than letting the service obtain its concrete dependencies. The term Dependency Injection may first sound like some very advanced technology but in reality there are absolutely no complex techniques behind it. As long as you understand abstractions and constructors and methods that can accept parameters you’ll understand DI as well.

Another related term is Inversion of Control, IoC. IoC is an older term than DI. Originally it meant a programming style where a framework or runtime controlled the programme flow. Sticking to this definition software that is developed with .NET uses IoC – in this case .NET is the controlling framework. You hook up to its events, lifetime management etc. You are in control of your methods and references but .NET provides the ultimate glue. Nowadays we’re so used to working with frameworks that we don’t care – we’re actually happy that we don’t need to worry about tedious infrastructure stuff. With time IoC drifted away to mean Inversion of Control Containers which are mechanisms that control dependencies. Martin Fowler was the one who came up with the term Dependency Injection to mean this particular flavour of IoC. Thus, DI is still the correct term to describe the control over dependencies although people often use IoC instead.

DIP is a large topic so it will span several posts to discuss it thoroughly. However, one important conclusion up front is the following:

The frequency of the ‘new’ keyword in your code is a rough estimate of the degree of coupling in your object structure.

A side note: in the demo I’ll concentrate on interfaces but DI works equally well with abstract classes.

The main source in the series on Dependency Injection is based on the work of Mark Seemann and his great book on DI.

What are dependencies?

Dependencies can come in different forms.

A framework dependency is your choice of the development framework, such as .NET. You as a .NET developer are probably comfortable with that dependency as it’s unlikely to change during the product’s lifetime. Most often if you need the product to run on a different framework then it will be rewritten for that platform in a different language without discarding the original product. As this dependency is very unlikely to change and it’s a very high level dependency we don’t worry about it in this context.

Third party libraries introduce a lower level dependency that may well change over time. If a class depends on an external dll then that class may be difficult to test as we need that library to be in a consistent state when testing. However, some of those dependencies may never change. E.g. if I want to communicate with the Amazon cloud in code then it’s best to download and reference the Amazon .NET SDK and use that for entire lifetime of the product. It’s unlikely that I will write my own SDK to communicate with the Amazon web services.

Databases store your data and they can come in many different forms: SQL Server, MySQL, MongoDb, RavenDb, Oracle etc. You may think that an application will never change its storage mechanism, but you’ll better be prepared and abstract it away behind a repository as we’ll see in the demo.

Some other less obvious dependencies include the File System, Emails, Web services and other networking technologies.

System resources such as the Clock to get the current time. You may think that’s unnecessary to abstract that away. After all, why would you ever write your own time provider if the System Clock is available? Think of unit testing a method that depends on time: a price discount is given between 5pm and 6pm on every Friday. How would you unit test that logic? Do you really wait until 5pm on a Friday and hope that you can make the test pass before 6pm? That’s not too clever, as your unit test can only run during that time. So there’s a valid point in abstracting away system resources as well.

Configuration in general, such as the app settings you read from the config file.

The new keyword, as hinted at in the introduction, generally points to tighter coupling and an introduction of an extra dependency. As soon as you write var o = new MyObject() in your class MyClass then MyClass will be closely dependent on MyObject(). If MyObject() changes its behaviour then you have to be prepared for changes and unexpected behaviour in MyClass as well. Using static methods is no way out as your code will depend on the object where the static method is stored, such as MyFactory.GetObject(). You haven’t newed up a MyFactory object but your code is still dependent on it.

Depending on threading-related objects such as Thread or Task can make your methods difficult to test as well. If there’s a call to Thread.Sleep then even your unit test will need to wait.

Anytime you introduce a new library reference you take on an extra dependency. If you have a 4 layers in your solution, a UI, Services, Domains and Repository then you can glue them together by referencing them in Visual Studio: UI uses Services, Services use the Repo etc. The degree of coupling is closely related to how painful it is to replace those layers with new ones. Do you have to sit for days in front of your computer trying to reconnect all the broken links or does it go relatively fast as all you need to do is inject a different implementation of an abstraction?

Getting random numbers using the Random object also introduces an extra dependency that’s hard to test. If your code depends on random numbers then you may have to run the unit test many times before you get to test all branches. Instead, you can provide a different implementation of generating random numbers where you control the outcome of this mechanism so that you can easily test your code.

I’ve provided a hint on how to abstract away built-in .NET objects in your code at the end of this post.

Demo

In the demo we’ll use a simple Product domain whose price can be adjusted using a discount strategy. The Products will be retrieved using a ProductRepository. A ProductService class will depend on ProductRepository to communicate with the underlying data store. We’ll first build the classes without DIP in mind and then we’ll refactor the code. We’ll keep all classes to a minimum without any real implementation so that we can concentrate on the issues at hand. Open Visual Studio and create a new console application. Add the following Product domain class:

public class Product
{
	public void AdjustPrice(ProductDiscount productDiscount)
	{
	}
}

…where ProductDiscount looks even more simple:

public class ProductDiscount
{
}

ProductRepository will help us communicate with the data store:

public class ProductRepository
{
	public IEnumerable<Product> FindAll()
	{
		return new List<Product>();
	}
}

We connect the above objects in the ProductService class:

public class ProductService
{
	private ProductDiscount _productDiscount;
	private ProductRepository _productRepository;

	public ProductService()
	{
		_productDiscount = new ProductDiscount();
		_productRepository = new ProductRepository();
	}

	public IEnumerable<Product> GetProducts()
	{
		IEnumerable<Product> productsFromDataStore = _productRepository.FindAll();
		foreach (Product p in productsFromDataStore)
		{
			p.AdjustPrice(_productDiscount);
		}
		return productsFromDataStore;
	}
}

A lot of code is still written like that nowadays. This is the traditional approach in programming: high level modules call low level modules and instantiate their dependencies as they need them. Here ProductService calls ProductRepository, but before it can do that it needs to new one up using the ‘new’ keyword. The client, i.e. the ProductService class must fetch the dependencies it needs in order to carry out its tasks. Two dependencies are created in the constructor with the ‘new’ keyword. This breaks the Single Responsibility Principle as the class is forced to carry out work that’s not really its concern.

The ProductService is thus tightly coupled to those two concrete classes. It is difficult to use different discount strategies: there may be different discounts at Christmas, Halloween, Easter, New Year’s Day etc. Also, there may be different strategies to retrieve the data from the data store such as using an SQL database, a MySql database, a MongoDb database, file storage, memory storage etc. Whenever those strategies change you must update the ProductService class which breaks just about every principle we’ve seen so far in this series on SOLID.

It is also difficult to test the product service in isolation. The test must make sure that the ProductDiscount and ProductRepository objects are in a valid state and perform as they are expected so that the test result does not depend on them. If the ProductService sends an email then even the unit test call must send an email in order for the test to pass. If the emailing service is not available when the test runs then your test will fail regardless of the true business logic of the method under test.

All in all it would be easier if we could provide any kind of strategy to the ProductService class without having to change its implementation. This is where abstractions and DI enters the scene.

As we can have different strategies for price discounts and data store engines we’ll need to introduce abstractions for them:

public interface IProductDiscountStrategy
{
}
public interface IProductRepository
{
	IEnumerable<Product> FindAll();
}

Have the discount and repo classes implement these interfaces:

public class ProductDiscount : IProductDiscountStrategy
{
}
public class ProductRepository : IProductRepository
{
	public IEnumerable<Product> FindAll()
	{
		return new List<Product>();
	}
}

When we program against abstractions like that then we introduce a seam into the application. It comes from seams on cloths where they can be sewn together. Think of the teeth – or whatever they are called – on LEGO building blocks. You can mix and match those building blocks pretty much as you like due to the standard seams they have. In fact LEGO applied DIP and DI pretty well in their business idea.

Let’s update the ProductService class step by step. The first step is to change the type of the private fields:

private IProductDiscountStrategy _productDiscount;
private IProductRepository _productRepository;

You’ll see that the AdjustPrice method of Product now breaks so we’ll update it too:

public void AdjustPrice(IProductDiscountStrategy productDiscount)
{
}

Now the Product class can accept any type of product discount so we’re on the right track. See that the AdjustPrice accepts a parameter of an abstract type? We’ll look at the different flavours of DI later but that’s actually an application of the pattern called method injection. We inject the dependency through a method parameter. We’ll employ constructor injection to remove the hard dependency on the ProductRepository class within ProductService:

public ProductService(IProductRepository productRepository)
{
	_productDiscount = new ProductDiscount();
	_productRepository = productRepository;
}

Here’s the final version of the ProductService class:

public class ProductService
{
	private IProductRepository _productRepository;

	public ProductService(IProductRepository productRepository)
	{
		_productRepository = productRepository;
	}

	public IEnumerable<Product> GetProducts(IProductDiscountStrategy productDiscount)
	{
		IEnumerable<Product> productsFromDataStore = _productRepository.FindAll();
		foreach (Product p in productsFromDataStore)
		{
			p.AdjustPrice(productDiscount);
		}
		return productsFromDataStore;
	}
}

Now clients of ProductService, possibly a ProductController in an MVC app, will need to provide these dependencies so that the ProductService class can concentrate on its job rather than having to new up dependencies. Obtaining the correct pricing and data store strategy should not be the responsibility of the ProductService. This relates well to the Open-Closed Principle in that you can create new pricing strategies without having to update the ProductService class.

It’s important to note that the ProductService class is now honest and transparent. It is honest about its needs and doesn’t try to hide the external objects it requires in order to fulfil its job, i.e. its dependencies are explicit. Clients using the ProductService class will know that it requires a discount strategy and a product repository. There are no hidden side effects and unexpected results.

The opposite case is a class having implicit dependencies such as the first version of the ProductService class. It’s not obvious for the caller that ProductService will use external libraries and it does not have any control whatsoever over them. In the best case if you have access to the code then you can inspect it and maybe even refactor it. The first version of ProductService tells the client that it suffices to simply create a new ProductService object and then it will be able to fetch the products. However, what do we do if the database is not present? Or if the prices are not correct due to the wrong discount strategy? Then comes the part where ProductService says ‘oh, sorry, I need database access before I can do anything, didn’t you know that…?”.

Imagine that you get a new job as a programmer. Normally all ‘dependencies’ that you need for your job are provided for you: a desk, a computer, the programming software etc. Now think how this would work without DI: you’ll have to buy a desk, get a computer within some specified price range, install the software yourself etc. That is the opposite of DI and that is how ProduceService worked before the refactoring.

A related pattern to achieve DI is the Adapter pattern. It provides a simple mechanism to abstract away dependencies that you have no control over, such as the built-in .NET classes. E.g. if your class sends emails then your default choice could be to use the built-in .NET emailing objects, such as MailMessage and SmtpClient. You cannot easily abstract away that dependency as you have no access to the source code, you cannot make it implement a custom interface, such as IEmailingService. The Adapter patter will help you solve that problem. Also, unit testing code that sends emails is cumbersome as even the test call will need to send out an email. Ideally we don’t test those external services so instead inject a mock object in place of the real one. How that is done? Start here.

View the list of posts on Architecture and Patterns here.

ultimatemindsettoday

A great WordPress.com site

Elliot Balynn's Blog

A directory of wonderful thoughts

Softwarearchitektur in der Praxis

Wissenswertes zu Webentwicklung, Domain-Driven Design und Microservices

Technology Talks

on Microsoft technologies, Web, Android and others

Software Engineering

Web development

Disparate Opinions

Various tidbits

chsakell's Blog

WEB APPLICATION DEVELOPMENT TUTORIALS WITH OPEN-SOURCE PROJECTS

Guru N Guns's

OneSolution To dOTnET.

Johnny Zraiby

Measuring programming progress by lines of code is like measuring aircraft building progress by weight.

%d bloggers like this: