views:

53

answers:

2

I'm trying to understand which objects should be injected into an object and which should be created internally.

  1. If i have some List<int> (as data field) which holds infomation gathered during run time. it seems that i should init it in the c'tor instead of injecting it.

but what about a hardware class which communicates through a COM port.

do i let the HW class init the SerialPort or i inject it ?

  1. If the above mentioned SerialPort needs to be injected; what is the best way to do it ?

do i create it manually :

SerialPort port = new SerialPort(name, baud ...);

HWClass hwClass = container.Reolve<IHWClass>("HWClass", new InjectionConstructor(port));

or using the Unity container

SerialPort port = conatiner.Resolve<SerialPort>(...);

HWClass hwClass = container.Reolve<IHWClass>("HWClass", new InjectionConstructor(port));

or should i init it inside the HWClass C'tor ?

adiel

+2  A: 

My general rule is that if the object can have it's state changed from outside your class or you want to be able to supply an alternate implementation either in testing or at some point in the future dynamically, you should inject it. If the class is only used and modified internally and the implementation is only dependent on the containing class, then creating the dependency internally is probably ok. To use your example, I would inject SerialPort, but not the List<int>.

As an aside, now that I do TDD (Test Driven Development), I find that I really don't worry too much about these decisions. You pretty quickly reach that point that you know which classes need to be injected in order to decouple your classes to make testing easier. Even if you don't get it right at first, within a few tests you find your code naturally evolving in that direction.

tvanfosson
+3  A: 

Domain-Driven Design distinguishes between Services and other Domain objects (Entities and Value Objects). Even if you don't otherwise subscribe to DDD, this distinction is very useful.

Services are typically long-lived, stateless objects that perform operations for their consumers. They are the typical dependencies that you can benefit greatly from injecting.

In your case, both SerialPort and IHwClass sounds very much like services because they represent external resources, so I would definitely inject them via Constructor Injection.

However, you only really gain the benefit of loose coupling if you inject an abstraction. The IHWClass looks fine because it's an interface, but the SerialPort looks like a concrete class, so you don't gain much from injecting it. Extracting an interface from SerialPort (say, ISerialPort) and injecting that instead would be better.

Mark Seemann
Or, for example, if a SerialPort inherits or acts like a stream, use a Stream as the interface instead.
strager
Thanks.Actually i refered to System.IO.Ports.SerialPort of the .net FW which is quite a concrete class. it seems quite artificial to wrap it with an interface just for injection purpose isnt it ?it sounds like "if it is not possible to extract an interface - don't inject !" am i wrong ?is there any benefit of creating the SerialPort using Unity or in this case it is the same as creating it by myself ?
Adiel
Wrapping an existing API is quite normal: http://stackoverflow.com/questions/3264992/wrapping-an-api-to-support-dependency-injection It certainly would be easier if an interface was already in place, but it's a worthwhile thing to do none the less.
Mark Seemann