Friday, February 22, 2008

IoC Containers generally, Castle Windsor specifically

First I’ll have a go at reinventing the wheel by trying to give my own definition of an IoC Container

An Inversion of Control (IoC) Container is a non-invasive configurable intelligent factory-component

Splitting this definition in parts, we get
  • Factory, because it is responsible for creating objects for you.

  • Intelligent, because it understands what dependencies you have, and create them for you recursively.

  • Configurable, because you can configure the usage through code or configuration files.

  • Non-invasive, because the objects used doesn’t need to know about the container.

An IoC Container really makes the Dependency Injection pattern a lot better. Why? I’ll look more into that throughout this post.

My previous post is a foundation for this one, as it explains the Dependency Injection pattern, and gives it a place in the world. I’ll use no time on that here. This post exists to build on that content, and show what more benefits you can achieve by using the dependency injection pattern with an IoC Container. This isn’t meant to be a comprehensive introduction to IoC Containers or Castle Windsor, but should give you a good idea of what it can do for you. Once you’ve read it, just continue on with what I’ve added in “References and further reading”.

I’ll use a simple example to help explain how it works. We have a client, which uses a service, which again depends on IStorageObject, which have two specific implementations. This is not meant as a real world example, but bear with me. The dependencies and sample implementation are shown below:












My previous post shows how we can handle this manually, and the pros and cons with the different solutions. We would like to get an instance of client, but we need to handle all the dependencies it has as well. If we have to write this manually, it will turn out as something like this:



This doesn’t look too bad, and the dependency injection approach is often better than a lot of alternatives. But think of it. As soon as this starts expanding, I can bet you that you’ll have a mouthful.

Now to do the same with an IoC Container, you can typically write:



For the container to create Client, it needs to create an instance of Client, but also an instance of both IService and IStorageObject. The container will understand that it needs to create both, and does so depending on how you have configured it. More on that later.

What if we add another dependency to the service implementation? The manual code would have to change to something like this (Each and every place service is created in the code. Resharper could help you quite a bit, but it’s far from a solution to the real issue.):



Already guessed how it would look with the container approach?



You are right, just the same :)


This has a number of advantages:
  • Easy to swap the implementation of an interface - just change the configuration.

  • If you find that Client suddenly needs another dependency, you don’t have to rewrite any of the Client creation code.

  • Removes explicit dependency-handling throughout the system

  • Single point to find out how objects are instantiated and connected

  • Easy to begin using Client in other places. (Less boilerplate code to write)

  • Additional benefits of tunneling dependencies through one source: Decorators, Interceptors, Proxies, as well as handling object lifestyle. Have a look here for a very good example.

  • See my previous post for more on the general benefits of dependency injection.

I am going to have a look at an IoC Container called Castle Windsor now. There are many other alternatives as well. I can’t speak too much about the others as I only have real life experience with this. If we talk only about the general dependency injection problem/solutions, the different projects have a lot of similarities, with some differences in support for config vs code, need for attributes etc.


Configuration and use - with XML

You can use a separate configuration file, or add the castle definitions to your app/web.config.



The configuration above states:
  • The string identifier of our only component is “storageobject”

  • The service (or interface) the container will create (if any - you don't need to specify one), is IStorageObject, from TheNamespace namespace

  • The specific implementation of this interface is DatabaseObject.

In practice, this means that if the container is ever asked for an implementation of “storageobject” or the IStorageObject interface, directly or through resolving dependencies, it will return an instance of DatabaseObject..



This code simply shows how the container would be started with this approach.


Configuration and use - with code

You can define everything in code:




The pros and cons of using XML versus code is that you can do changes without recompiling with the XML approach, while it is type safe when you specify it in code. Use whatever is best for your situation.


Lifestyle

Advanced handling of the lifestyle of objects has never been so easy. By adding a keyword, you can specify how your object lifestyle will be:



The previous configuration updated with specification of lifestyle:




Facilities

Adds integration with other tools
  • NHibernate

  • ActiveRecord

  • WCF integration

  • Remoting

  • Logging

  • Startable

  • Custom

  • +++

Other

Castle has a number of other possibilities as well, like specifying what to do when objects are created and destroyed (Commision and Decomission).

Note

The last couple of points feels kind of pointless without giving them much extra attention, but I'll leave that to other people who have described it much better. A good starting point would be this or this.

References and further reading

Inversion of Control and Dependency Injection with Castle Windsor Container - Part I (Simone Busoli)

Inversion of Control and Dependency Inject: Working with Windsor Container (Ayende)

A not so interesting post, with much more interesting comments.

Castle Windsor tutorials (BitterCoder's Wiki)

Inversion of Control Containers and the Dependency Injection pattern (Martin Fowler)

Castle Project

Conclusive thoughts

Although a short introduction, I hope I have captured enough information to get you interested. I’ve been using Castle for quite some time on my last project, and I am very happy with the results. I advise you to give it a try!

_

Tuesday, February 19, 2008

Objects, dependencies and patterns to manage it

The purpose of this post is to pass on knowledge about an important aspect of software development, with the hopes that someone else can have use for it. It is a presentation I held at work changed into written form.

The topic is managing dependencies between objects; how it affects the systems we build, and a few thoughts on different ways to handle it. We are going to look at three patterns: Factory, Service Locator and Dependency Injection, which in various ways help us control the dependencies. The purpose here is not to explore all the details of the various patterns, but rather to capture how the patterns handle these situations in general.

As a way of comparing the patterns, I’ve put together a few well known principles that has important things to say on the quality of software.

Simplicity

  • Complexity is so important to handle. Complex code is hard to read, change and manage. The challenge is to write code that people understand, not just code that compiles.
Separation of concerns (SoC) / High cohesion
  • Software that separates its different parts well is easier to understand and manage. The more a unit of code,which from now on should be understood as either a module, class or method, handles only a separate piece of the puzzle, the better. The Single Responsibility Principle fits well here: One unit of code should do only one thing, and do it very well.
Loose coupling
  • How much your unit of code depends on other parts of the system. Less coupling means code that is easier to understand, maintain and reuse in different contexts.
Ease of change
  • Highly related to all of the points above. We want code that is easy to change. The reason for this is of course that there are few environments were things change more often, be it because of business or technological needs, or really just realizing the nature of most software projects.
Encapsulation
  • Design choices that are not important to know of outside of your unit of code, should not be visible there either. It only increases complexity, makes things harder to change, and removes focus from what is really important.
Testability
  • Highly testable code has a number of benefits for the quality of your system, and is an important principle to live up to for the vast majority of projects.

I have created an example we will use throughout the post. It consists of two elements, a client and a service. The simplicity makes it impossible not to understand, as well as hopefully easier to relate to a number of situations, though making it harder to show real world problems and their solutions directly.



The service could be anything from an in-process calculator to an expensive web service or database service. The context has a lot to say for the conclusions, and it is vital that you relate the examples that will follow to the many similar situations you see on a daily basis. Depending on whether we would expect change here, we might or might not include an interface.

This is an example of the implementation of Client (in C#):



Potential problems with this code
  • It is hard to change, because it is connected to a concrete implementation of the service in the constructor.
  • You need to read the Client code to find that it has a dependency to Service.
  • Testability would be hurt if this was a resource-expensive or unreliable service.
Potential advantages of this code
  • It might do exactly what it needs to do - If it seems natural that Client should be responsible for creating Service, if there is no benefit of changing the implementation of Service in different situations, if testing isn’t hurt by not accessing it, then by all means keep it as simple as you can. YAGNI (You ain’t gonna need it) and KISS (Keep it simple, stupid) are important principles to follow.

  • As a side note concerning testing: It is possible to test this with TypeMock.

What if we increase the complexity of this example? Let's add an IStorageObject, which is a common interface for two ways of storing data, DatabaseObject and CacheObject. As the diagram below shows, Service now has a dependency towards DatabaseObject (And to IStorageObject, though not shown explicitly).



And the implementation:





As simple as this example is, we already have a potential for tight coupling. Even though we are coding to interfaces, this is not that easy to change. Reusing Client or Service in a different context is very hard. Replacing the implementation with a mock or stub during testing is in most cases impossible. And even though this example hides it, both Service and Client is now responsible for both creating and using the dependency, responsibilities we often want to separate (e.g. because of complex initialization). In real life, the complexities and couplings are often increased tenfold, and only then can you see the true value of these principles.


Pattern #1 - Factory

The factory pattern is one of the GoF patterns, a creational pattern, responsible only for creating objects. I have created a dead simple implementation of the factory pattern, where you have a ServiceFactory class with a static method to give you the concrete instance you want.



The dependencies can be modeled like this:




Advantages
  • Client only has a direct dependency on IService now, not the concrete initialization.

  • The code is more testable, if we have a factory where we can switch the concrete instance with a mock object.

  • The usage of Service will be clearer and easier to start using as all creational logic has been separated.

  • Having a single place to get instances of a service means you have more general possibilities, like the transparent handling of instances (always new or singleton). I will look at others throughout this and the next post.

  • We have separated the responsibility of creating and using the service. If creating a service means several manual steps to configure it, then this is even more valuable.

  • The Factory could return a different implementation based on input, a common reason to use a factory.
Problems
  • In our situation, we still have a compile time dependency on the specific IService implementation. The dependency has only moved a step out.

  • Reuse of Client in different contexts is hard, because of the still tight coupling to Service.

  • If we look back at the example with the deeper dependencies. Should we make another factory to handle this creation? Has this really loosened the coupling that much, and do we want to use all our time writing boilerplate factory-code?

  • We still have to read the implementation of Client to find that it has a dependency towards Service.

That being said, let’s look at how it lives up to the different principles listed in the beginning


Simplicity
  • The factory pattern is easy to use, and is one of the most known patterns. Thus, using it will help give clarity to what you try to achieve, even to developers less versed in the "patterns world". Though it is not correct in every situation, and too many factories is not necessarily a good thing either.
Separation of concerns (SoC) / High cohesion
  • The creation and use of a dependency is separated.
Loose coupling
  • The example still has a compile time dependency on the concrete implementation of IService. In many cases the factory pattern can help with the coupling, for instance by sending in some form of input.
Ease of change
  • Reusing Client in a different context is hard because of the still tight coupling.
Testability
  • If the implementation of the factory allows you to switch implementations, then yes, it is more testable. You need to initialize the factory with every test however, and even switch back again to the previous implementation to make sure that you don’t break other tests.



Pattern #2 – Service Locator

An (potentially global) object that gives access to services the application needs.


The example changes to:





Instead of the factory class we now have the service locator that creates and/or returns the service. The biggest change here is that you now have an assembler class which typically configures the Service Locator with the correct instances.

Two points concerning the implementation
  • In the example above I have used a string to get the correct type of service. This might as well have been solved with sending in a type or using generics if you want type safety and support for refactoring, at the cost of some flexibility though.

  • The example uses a Service Locator interface to separate the LocateService method from the methods Assembler uses to register services. The implementation is still a singleton, and could be changed to not use GetInstance first.


Advantages
  • Encapsulates the logic to find services.

  • A separate interface to deal with.

  • A central point of control. Easier to do similar things with the services you get, like handling instances and caching.

  • Can add a mock implementation during testing.
Problems
  • Hard to handle deeper dependencies well.

  • Advanced initialization of objects, which the factory does so well, is hard.

  • Possibly code to reset the service locator to make sure that one test does not break others.


And onto the principles:


Simplicity
  • Easy to use. A single method to call.
Separation of concerns (SoC) / High cohesion
  • The creation and use of a dependency is separated.
Loose coupling
  • If you have an implementation that uses an XML file to configure up the specific instances, then there is no compile time dependency.
Ease of change
  • As there is less coupling, it is easier to change as well. Reusing Client in a different context is still often troublesome though.
Testability
  • This pattern does make it even easier to test than Factory, but you still have to write extra code to create and change the service locator.



Pattern #3 – Inversion of Control / Dependency Injection

A fancy word for a really simple principle: it simply means injecting dependencies.







As you can see in the images above, Client now receives the specific implementation of IService from the outside.

Before going further, I think it is necessary to write a couple of lines about the confusion concerning the two concepts Inversion of Control and Dependency Injection. Inversion of Control is a common concept in computing. It relates to a situation where you instead of taking the active approach and asking for something, the framework is the active part that calls you. (i.e. events, the startup method of an application, etc) Dependency Injection is a specific form of Inversion of Control, where instead of asking for a specific dependency (As was done with Factory and Service Locator), the dependency is handed to you.

There are three types of Dependency Injection: Constructor, Setter and Interface injection.

Constructor injection
- what is shown above, injecting the dependencies in the constructor.

Advantages
  • Any user of Client will see that it has a dependency on IService.

  • Unlike the other injection approaches, Client is completely initialized once created, as you can’t create it without giving it an instance of IService.

  • You can set IService as ReadOnly, since it is set in the constructor.
Problems
  • If you have optional dependencies, especially if they are resource-intensive to create, then it is not a good idea to initialize them in the constructor.

  • If you have many optional dependencies, and want to give a separate constructor for each valid case, then you soon end up with a lot of constructors.


Setter injection
- Injecting the dependency through a property.



Advantages
  • Good way to handle optional dependencies, especially if they are resource-intensive.

  • Support for Dependency Injection in legacy code without having to change the constructor, for instance to improve testing, or to add new functionality.
Problems
  • Harder to know what you need to do to use the object, which can lead to surprises.

  • Somewhat harder to track down exceptions.


Interface injection
– a special form of setter injection: Specifying injector methods in an interface.



As this is almost identifcal to Setter injection, there isn’t much else to say about it. The only difference is that it can help separate out what are really dependencies that must be filled. However, this seems to be the least used form of dependency injection.


Advantages of using Dependency Injection in general
  • Easier to test: You can simply inject a mock.

  • Potential for less coupling, as it doesn’t ask for a specific implementation.

  • Easy to reuse Client in different contexts, because of the point above.

  • Not necessarily compile time binding. And even if so, different implementations of Client can easily be bound to different implementation of IService.
Problems
  • You’re not supposed to inject everything. One problem is that you can break encapsulation, another that you should take care not to create interfaces for all objects in your system. Coding to interfaces is a good thing, but making interfaces where you don’t expect change or testing isn’t a good enough reason, will make it hard to see where you truly expect change in the system.

  • It can be cumbersome to do Dependency Injection manually. I look at a solution for that in my next post.


So how does Dependency Injection live up to the initial principles?


Simplicity
  • Simple to write and understand. But writing manually can be time-consuming.
Separation of concerns (SoC) / High cohesion
  • The creation and use of a dependency is separated. Also, Client only uses the dependency now. Compared to the other patterns, Client doesn’t even need to ask for an implementation.
Loose coupling
  • The code has a potential for even less coupling, as it only uses it's dependencies.
Ease of change
  • Easy to change in terms of using Client in different contexts, but manual dependency injection code isn’t any easier to change.
Encapsulation
  • Don’t break encapsulation where it’s not natural.
Testability
  • By far the easiest way of testing objects where you need to add a mock implementation.


References and further reading

Inversion of Control Containers and the Dependency Injection pattern [Martin Fowler]

A few of the posts on a longer discussion of Dependency Injection: (You can find more from each)
Dependency Injection
Dependency Injection: More than a testing seam
Defending Dependency Injection
Dependency Injection - Keep your privates to yourself

Dependency Injection - MSDN Magazine
Guice video. Some good general points as well, if you're bored with reading.
Applying Domain-Driven Design and Patterns (Book) - On Dependency Injection and Service Locator

GoF (Book) - On Factory
Head First Design Patterns (Book) - On Factory

Conclusive thoughts

At the outset of creating this presentation, I was planning to only write about the Dependency Injection pattern. However, I felt that putting it in a bigger context, and trying to present the different patterns in a more uncommon way would be more helpful. This is by far perfect, but if it can help anyone better see the usage of these patterns and part of their place in the world, then it was worth rewriting this for the web. Not the least, if anyone can further educate me as well, what could be better?

This was part 1 of the presentation. Part 2 handles IoC Containers, and how you can do Dependecy Injection without having to do it manually.