I've been using Dependency Injection for a while, and now I want to give a talk about IoC and DI to a group of new developers. I remember explaining it to one guy personally and he asked me:
"Why not just use:
private IMyInterface _instance = new MyImplementaion();
instead of going through all the DI trouble. "
My answer was: "Unit testing requires mocks and stubs." - but we do not write unit tests in my company so it did not convince him. I told him that concrete implementation is bad since you are tightly coupled to one implementation. Changing one component will cause change in another.
Can you give an example for such code?
Can you give me more reasons why this code is bad?
It seem so obvious to me that I have trouble explaining it :-)
The problem with the following coupling
public class MyClass
{
private IMyInterface _instance = new MyImplementation();
...
Means that any time MyClass is created (whether directly, or by an IoC container) is that it will always immediately create a concrete MyImplementation and bind its dependency _instance to this concrete implementation. In turn, it is likely that MyImplementation has other dependencies, which are also coupled this way.
Benefits of decoupling of classes such that MyClass is only dependent on interfaces to its dependencies, and not concrete implementations of the dependencies (i.e. the D of SOLID principles) include:
for Unit Testing - As you've mentioned, in order to test MyClass in isolation, with new'ed dependencies, you would need to resort to nasty things like Moles / Fakes in order to mock out the the hard wired MyImplementation dependency.
for Substitution - by coupling only to an interface, you can now swap out different concrete implementations of IMyInterface (e.g. via configuring your IoC bootstrapping) without changing any code in MyClass.
for making dependencies explicit and obvious in your system, as the IMyInterface dependency may have further dependencies, which need to be resolved (and may need configuration considerations as well). If MyClass hides the IMyInterface dependency internally, it is not visible to the caller as to what the dependencies of MyClass are. Although in classic 1990's OO this was commonplace (i.e. encapsulation + composition), this can obscure the implementation as deployment of all dependencies still needs to be done. However, with coupling done on interface level (i.e. consumers of MyClass will do so only via IMyClass), the coupling-visible interface is IMyClass which will again hide the dependency on IMyInterface, since constructors are not visible on the interface).
for configurable dependency lifespan control. By injecting IMyInterface, instead of newing MyImplementation, you are allowing additional configuration options with respect to the lifespan management of the MyImplementation object. When the original hardwired creation of MyImplementation was done on MyClass, it was effectively taking ownership of MyImplementation's lifespan with a 1:1 relationship between the two class instances. By leaving this to the IoC container, you can now play with other options of MyImplementation's lifespan, which might be more efficient, e.g. if MyImplementation instances are thread-safe, you may elect to share an instance across multiple instances of MyClass, for instance.
In summary, here's how I believe the refactoring should look suitable for IoC constructor dependency injection:
public class MyClass
{
// Coupled onto the the interface. Dependency can be mocked, and substituted
private readonly IMyInterface _instance;
public MyClass(IMyInterface instance)
{
_instance = instance;
}
...
The IoC container bootstrapping will define WHICH implementation of IMyInterface needs to be bound, and will also define the lifespan of the dependency, e.g. in Ninject:
Bind<IMyInterface>()
.To<SomeConcreteDependency>() // Which implements IMyInterface
.InSingletonScope();
Related
I have a Data Repository interface called IRepository. BakerRepository inherits the generic CRUD methods from it. Now for BakerRepository, it may have some methods that are special to itself. For example, a method called Bake.
I am using Unity.Mvc for the container of the dependencies. This was how I originally use it in the controller, which I learned from a tutorial that I read a few days ago:
private IRepository<Baker, int> _repository;
public BakersController(IRepository<Baker, int> repo)
{
_repository = repo;
}
The container will basically give me the BakerRepository implementation. However, when I try to use the Bake method, which is unique to BakerRepository, it returns an error because _repository is of type IRepository<Baker, int>, and thus knows no Bake method.
So I tried this implementation instead:
private BakerRepository _repository;
public BakersController(IRepository<Baker, int> repo)
{
_repository = repo as BakerRepository;
}
I don't fully understand the DI pattern, I'm only using it now because I learned it as a part of a tutorial about data repositories in ASP.Net MVC. I read up about it and I thought it's actually a good design pattern so I decided to keep using it, although I don't get it a hundred percent.
Now I'm wondering if I rendered the purpose dependency injections useless if I do the implementation this way. I don't understand DI pattern enough, and I just couldn't find an exact answer elsewhere.
Casting the IRepository<Baker, int> in the constructor to BakerRepository violates at least two out of 5 SOLID principles:
Open/Closed Principle is violated, because this will cause changes to a different part of the system (the replacement or decoration of the repository for instance) to cause sweeping changes throughout the system, since you might be using the BakerRepository in many places.
Interface Segregation Principle is likely violated, because it is unlikely that your BakersController uses all BakerRepository method.
Dependency Inversion Principle is violated, because your BakersController depends directly on a concrete type, instead of an abstraction. This makes it harder to change and evolve implementations independently.
None of these problems can be solved by changing the the IRepository<Baker, int> parameter to BakersRepository. Instead, you should break out this special Bake method and place it behind its own abstraction, for instance:
public interface IBakeHandler
{
BakeResults Bake([parameters]);
}
You can mark the BakeRepository with this new IBakeHandler interface as well:
class BakeRepository : IRepository<Bake>, IBakeHandler
{
}
This allows you to let the BakeController to depend on IBakeHandler instead:
private IBakeHandler _bakeHandler;
public BakersController(IBakeHandler bakeHandler)
{
_bakeHandler = bakeHandler;
}
This prevents violating of the SOLID principles, because:
The replacement of the implementation with a proxy, decorator or adapter will not ripple through the system; the BakerController is unaffected by such change.
The IRepository<T> and especially the IBakeHandler stay narrow, making it much easier to create decorators to apply cross-cutting concerns or to create mock/stub/fake implementations for testing.
Repository and IBakeHandler implementations can be placed in assemblies that are unreferenced by the assembly that holds the controller.
Do note though that every time you break open such repository implementation to add new features you are effectively violating the Open/Closed principle and probably the Single Responsibility Principle as well.
In case you have many of those 'extra' repository features, you will start to see many one-method interfaces like IBakeHandler. Once you see this happening, extract new generic abstractions out of these interfaces. You can apply well-known patterns such as described here and here.
The right answer is to actually pass the BakerRepository to your BakerController, because that's what it depends on.
Dependency injection is, as you say, a very useful pattern. However, it is just a tool to help build your objects when you've properly extracted the dependencies of your classes. In a non framework setting you'd be responsible for building these objects, and you'd quickly tire of passing in loads of parameters. DI helps you with that. But it is optional. So, if you did it by hand, you'd always construct the BakerController with a BakerRepository passed in. Therefore the same logic would apply when you're using DI.
In direct answer to your question. You could upcast your dependency but that would have no bearing on what D\I does for you.
Breaking out your dependencies CAN be useful for TDD also, isolating your external dependencies allows for unit testing of a class without exercising relatively expensive I\0 calls or disruptive calls.
Also breaking out dependencies allows you to focus the responsibilities of an object and having object doing one thing well.
In practice I have rarely seen or used D\I (implemented off the back of an IOC container) to change concrete implementations, having only done it recently for feature toggling
Another point is that objects which are not external I\0 could feasibly be newed up and still tested either sociably or in a solitary manner.
You shouldn't necessarily D\I everything....
I am studying IoC, DDD and AOP concepts. I've read a number of articles, docs, Ninject manual (i'm restricted to use .NET 3.5), tried some stuff and so on.
It's hard to shove everything at once to my head, but motivation, concepts and technical matters are somewhat clear. And i'd been always feeling that i was missing something.
Firstly, as i understand IoC containers' purpose is initial object structure set up?
Like, set up container in composition root, create "main" object, that is being wired all the way by IoC container.
Then, as i understand, later all objects are instantiated with factories? Although i can't help myself to perceive factory as a case of service locator (that ended up considered antipattern and by the way is used as core mechanics of IoC containers).
So the question is:
What if i want to create an instance with slightly different structure, e.g. i have
interface IFoo{}
interface IBar{}
class SomeClass
{
SomeClass(IFoo obj){...}
}
class Foo : IFoo
{
Foo(IBar obj){...}
}
class Bar : IBar
{
}
class FooBar : IBar // also implements IBar interface
{
}
So, initial binding configuration is making SomeClass.Foo.Bar structure. Assume, i also need SomeClass.Foo.FooBar. What do i do? The options i can think of:
reconfigure bindings 'in place': just no.
have a constructor parameter for top class, that has configuration for whole structure. that's pretty awful. aside from the fact that all subsequent constructors (and all other project classes constructors, in the end, i'm sure) will have to have one more parameter, it is not clearly seen, how it will function and not use some dirty tricks.
substitute what is needed after object was created. it either breaks law of demeter (about which i'm not concerned too much, but in this case it's too rude) and a couple of other principles or, in general case, isn't possible at all.
use factory that is configured somehow. it just defers/transfers the need itself to later/other place in code
use some kind of contextual/conventional binding. one solution i see (didn't test yet) it's to go all the way to the top of "activation root", check, what's creating the hierarchy. m.b. we'll have to make decorator for top level class, for container to check its type and behave accordingly. actually, container may be configured in a manner, that it decides, what concrete instance to inject by "parsing" top level interface's name. something like
ICfg_ConcreteType1_ConcreteType2_...
the problems here (besides that it looks like hack):
a) we must introduce some mnemonic system, which is not obscene/user friendly.
b) we must have rules/decorators for every factory with this "feature" (but looks like we can somewhat simplify the process at least with rules)
c) it resembles me of reflection usage with convention over configuration, which i'm averted of and treat it as a hack.
Or we may use attributes to set this up. Or may be i just don't know something.
Firstly, as i understand IoC containers' purpose is initial object structure set up?
Forget about IoC containers for a moment. Dependency Injection is not about using tools. It's first and foremost about applying principles and patterns. The driving force behind Dependency Injection are the SOLID principles. I would even go as far as start your application without using an IoC container at all, and only start using one when is a really compelling reason to do so. This means that you simply build up the object graphs by hand. The right place to do this is in your Composition Root. This should be the single place where you compose your object graphs.
And do note that this advice comes from someone who is building and maintaining a IoC container himself.
Then, as i understand, later all objects are instantiated with factories?
When practicing Dependency Injection, you will see that the need to use factories actually minimizes. They can still be useful, but I only use them sparingly nowadays.
Reason for this is that a factory usually just adds an extra (useless) layer of abstraction.
When starting with making code more loosely coupled, developers are tempted to use a factory as follows:
public class SomeClass
{
public void HandleSomething() {
IFoo foo = FooFactory.Create();
foo.DoSomething();
}
}
Although this allows a Foo implementation to be decoupled from SomeClass, SomeClass still takes a strong dependency on FooFactory. This still makes SomeClass hard to test, and lowers reusability.
After experiencing such a problem, developers often start to abstract away the FooFactory class as follows:
public class SomeClass
{
private readonly IFooFactory fooFactory;
public SomeClass(IFooFactory fooFactory) {
this.fooFactory = fooFactory;
}
public void HandleSomething() {
IFoo foo = this.fooFactory.Create();
foo.DoSomething();
}
}
Here a IFooFactory abstraction is used, which is injected using constructor injection. This allows SomeClass to be completely loosely coupled.
SomeClass however now has two external dependencies. It both knows about IFooFactory and IFoo. This duplicates the complexity of SomeClass, while there is no compelling reason to do so. We will immediately notice this increase of complexity when writing unit tests. We will now suddenly have to mock two different abstactions and test them both.
Since we are practicing constructor injection here, we can simplify SomeClass -without any downsides- to the following:
public class SomeClass
{
private readonly IFoo foo;
public SomeClass(IFoo foo) {
this.foo = foo;
}
public void HandleSomething() {
this.foo.DoSomething();
}
}
Long story short, although the Factory design pattern is still valid and useful, you will hardly ever need it for retrieving injectables.
Although i can't help myself to perceive factory as a case of service locator
No. A factory is not a service Locator. The difference between a factory and a locator is that with a factory you can build up only one particular type of objects, while a locator is untyped. You can build up anything. If you use an IoC container however, you will often see that the factory implementation will forward the request to the container. This should not be a problem, because your factory implementation should be part of your composition root. The composition root always depends on your container and this is not a form of Service Location, as Mark Seemann explains here.
Or we may use attributes to set this up. Or may be i just don't know something.
Refrain from using attributes for building up object graphs. Attributes pollute your code base and cause a hard dependency on an underlying technology. You absolutely want your application to stay oblivious to any used composition tool. As I started with, you might not even use any tool at all.
For instance, your object graph can be composed quite easily as follows:
new SomeClass(
new Foo(
new Bar()));
In your example, you seem to have two IBar implementations. From the context it is completely unclear what the function of this abstraction and these implementations are. I assume that you want to be able to switch implementations one some runtime condition. This can typically be achieved by using a proxy implementation. In that case your object graph would look as follows:
new SomeClass(
new Foo(
new BarProxy(
new Bar(),
new FooBar()));
Here BarProxy looks as follows:
public class BarProxy
{
private readonly IBar left;
private readonly IBar right;
public BarProxy(IBar left, IBar right) {
this.left = left;
this.right = right;
}
public void BarMethod(BarOperation op) {
this.GetBar(op).BarMethod(op);
}
private IBar GetBar(BarOperation op) {
return op.SomeValue ? this.left : this.right;
}
}
It's hard to say when you should start using a DI container. Some people like to stay away from DI containers almost always. I found that for the type of applications I build (that are based on these and these patterns), a DI container becomes really valuable, because it saves you from having to constantly update your Composition Root. In other words:
Dependency Injection and the SOLID principles help making your application maintainable. A DI library will help in making your composition root maintainable, but only after you made your application maintainable using SOLID and DI.
You would generally use some sort of tag system.
http://www.ghij.org/blog/post/2014/05/19/how-to-tag-classes-to-determine-which-to-reflect-with-mef.aspx
Let us assume I have an interface
public interface IMyInterface { }
And a class that exposes this interface as a property:
public class MyClass
{
public IMyInterface Property { get; set; }
}
MyClass is registered as a Singleton with my Windsor container. I would like to wire up the windsor container so that IMyInterface resolves to the property "Property" on the instance of MyClass, which I can achieve as follows:
container.Register(Component.For<MyClass>().ImplementedBy<MyClass>().LifeStyle.Singleton);
var myClass = container.Resolve<MyClass>();
container.Register(Component.For<IMyInterface>().Instance(myClass.Property));
However, I would prefer to have the container do all my resolving for me so I don't have to make the call to container.Resolve above. Is there a way to achieve this?
If the MyClass is responsible of creating that instance, you can't magically remove the registration for IMyInterface. You need to register something, but your configuration can be made a bit simpler by using a factory delegate as follows:
container.Register(Component.For<IMyInterface>()
.UsingFactoryMethod(() => container.Resolve<MyClass>().Property)
.LifeStyle.Transient);
If you register the IMyInterface as a singleton, there will be only one instance of the component; any resolution will return the same instance. Whether it comes from the property or not does not change the resolution
In fact this behavior by the container makes me question why it is important that you resolve through a particular accessor? Is there some additional processes in the getter to the property you've not mentioned?
Regarding the fact you don't want to resolve the MyClass to access its property, You have to retrieve an instance of the class if you don't make the property static, you won't be able to sidestep this.
Is this IMyInterface the interface from the third party library which you implement in order to use it? If this is so than I can conclude IMyInterface is 100% needed for your implementation to work.
An important note to keep in mind - Any software developer who encounters your class will not know that IMyInterface is real dependency of this class because it is a property - anybody can reset it somewhere. When you put your dependencies in ctor your are guaranteed that everybody will notice that this is a hard dependency without which the class is not supposed to work. In general - "hard" dependencies come through ctor, others may be exposed as properties.
However, in the interests of keeping the number of "moving parts" at a minumum to make the API more palatable I am happy to sacrifice a "purer" dependency injection philosophy in favour of fewer registrations.
Keep in mind that the DI principles come from practice and maintainability and readability must outweigh palatability. If somebody else maintains your code it will be easier to spot the dependency in ctor rather than as a property. Therefore palatability is an illusion because you know what your code is doing (now).
My advice is to stay with constructor injection of IMyInterface and just make a typed factory and get it through the constructor.
We are building an ASP.NET project, and encapsulating all of our business logic in service classes. Some is in the domain objects, but generally those are rather anemic (due to the ORM we are using, that won't change). To better enable unit testing, we define interfaces for each service and utilize D.I.. E.g. here are a couple of the interfaces:
IEmployeeService
IDepartmentService
IOrderService
...
All of the methods in these services are basically groups of tasks, and the classes contain no private member variables (other than references to the dependent services). Before we worried about Unit Testing, we'd just declare all these classes as static and have them call each other directly. Now we'll set up the class like this if the service depends on other services:
public EmployeeService : IEmployeeService
{
private readonly IOrderService _orderSvc;
private readonly IDepartmentService _deptSvc;
private readonly IEmployeeRepository _empRep;
public EmployeeService(IOrderService orderSvc
, IDepartmentService deptSvc
, IEmployeeRepository empRep)
{
_orderSvc = orderSvc;
_deptSvc = deptSvc;
_empRep = empRep;
}
//methods down here
}
This really isn't usually a problem, but I wonder why not set up a factory class that we pass around instead?
i.e.
public ServiceFactory
{
virtual IEmployeeService GetEmployeeService();
virtual IDepartmentService GetDepartmentService();
virtual IOrderService GetOrderService();
}
Then instead of calling:
_orderSvc.CalcOrderTotal(orderId)
we'd call
_svcFactory.GetOrderService.CalcOrderTotal(orderid)
What's the downfall of this method? It's still testable, it still allows us to use D.I. (and handle external dependencies like database contexts and e-mail senders via D.I. within and outside the factory), and it eliminates a lot of D.I. setup and consolidates dependencies more.
Thanks for your thoughts!
One argument against this is that it doesn't make your dependencies clear. It shows that you depend on "some of the stuff in the service factory" but not which services. For refactoring purposes it can be helpful to know exactly what depends on what.
Dependency injection should make this kind of thing easy, if you're using an appropriate framework - it should just be a matter of creating the right constructor, defining what implements which interface, and letting it sort everything out.
Such a factory is essentially a Service Locator, and I consider it an anti-pattern because it obscures your dependencies and make it very easy to violate the Single Responsibility Principle (SRP).
One of the many excellent benefits we derive from Constructor Injection is that it makes violations of the SRP so glaringly obvious.
If most of your classes depend on this three interfaces you could pass an object around that wraps them together, BUT: if most of the classes just depend on one or two of them then it's not a good idea since those classes will have access to objects they don't need and they have no business with and some programmers will always call the code they are not supposed to call just because it's available.
Btw, it's not a factory unless you always create a new object in the Get[...]Service() methods and doing that just for passing a few methods around is bad. I'd just call it ServiceWrapper and turn them into the properties EmployeeService, DepartmentService and OrderService.
I'm trying to come to terms with using IoC/Dependency Injection while at the same time programming to contracts rather than specific classes. The dilemma I'm having is the tension between:
Do program to interfaces for IoC: I started out with IoC relying heavily on interfaces. Judging by Spring's sample projects, interfaces are the way to go when programing to a contract with IoC.
( ... although abstract classes generally preferred: the main drawback of interfaces is that they are much less flexible than classes when it comes to allowing for evolution of APIs )
Do make class dependencies explicit via constructor
My gut feeling is that it's good programming practice to pass dependencies in to a class's constructor. Indeed, this is dependency injection.
... except you can't enforce constructor signature in interfaces/abstract clases: Neither interfaces or nor abstract classes allow for defining a constructor signature ( easily / elegantly ).
See also Framework Design Guidelines section 4.4: DO NOT define public or protected internal constructors in abstract types. ... Constructors should be public only if users will need to create instances of the type.
This question is related to a previous stackoverflow question: Interface defining a constructor signature?
But my question is:
Since you can't define a constructor in a C# interface/abstract class, as the question above asks, on a practical level:
How do you reconcile this with the sensible practice of passing dependencies in via a constructor?
Edit: Thank you for the answers. I'm hoping for some insight on what I should do in this case. Just not use contructor args? Use some sort of Init() method that does take the dependencies?
Edit2: Thanks for the great answers, very helpful.
I always think this is easier to explain with a (made up) example...
Imagine you have an ICustomerRepository interface, an IShoppingCartRepository interface and an ICheckout interface. You have concrete implementations of those interfaces - CustomerRepository, ShoppingCartRepository, and CheckoutService.
Your CheckoutService concrete class has a constructor that takes an ICustomerRepository and an IShoppingCartRepository - e.g.
public CheckoutService(ICustomerRepository customerRepository, IShoppingCartRepository shoppingCartRepository)
{
// Set fields for use in some methods later...
_customerRepository = customerRepository;
_shoppingCartRepository = shoppingCartRepository;
}
Then, when you want an ICheckoutService implementation to do some work with, you tell your IoC container which concrete class it should use for each interface type and ask it to build you an ICheckoutService. Your IoC container will go and build your classes for you, injecting the correct concrete classes into the constructor of your CheckoutService. It will also build dependencies all the way down the class heirarchy here, so if, for example your ShoppingCartRepository takes an IDatabaseSession interface in the constructor, your IoC container will inject that dependency too, as long as you have told it which concrete class to use for your IDatabaseService.
Here's some code you might use when configuring (for example) StructureMap as your IoC container (this code would typically be called during app startup):
public class AppRegistry : Registry
{
public AppRegistry()
{
ForRequestedType<ICheckoutService>().TheDefaultIsConcreteType<CheckoutService>();
ForRequestedType<ICustomerRepository>().TheDefaultIsConcreteType<CustomerRepository>();
// etc...
}
}
Then to get an instance of ICheckoutService built up and ready to go, with all the dependencies passed into the constructor for you, you would use something like:
var checkoutService = ObjectFactory.GetInstance<ICheckoutService>();
I hope that makes sense!
Your IoC container must construct an object from a concrete type, even though what you're passing around is an interface. Your constructor is not a behavior or state contract, so it does not belong in an interface or as a public member of your abstract class.
A constructor is an implementation detail, so you do not need to separate its definition from the concrete class.
You cannot define constructor signatures in interfaces. That wouldn't make sense anyway since the interface shouldn't enforce how the implementations are constructed.
Abstract classes though can indeed have constructors. They must be protected since public constructors does not make sense either. They should only be called by concrete subclasses.
The IoC principle dictates that instead of having class A know about and instantiate class B, you should instead pass in a reference to IB to the constructor of A. Then A will not need to know about class B and thus you can easily substitute class B with some other implementation of IB.
Since you're passing in an already instantiated object of class B, the IB interface doesn't need to have a constructor signature.