0

I've come across the fact how using the new Keyword results in hard to test code. The solution to this seems to be passing the dependencies in the constructor and instantiating objects in Factories only. But what if we don't know all the dependencies ( or the types of dependencies ) at object instantiation time? How to handle such cases?

For example let us say that we have a tree which can have different types of nodes. Upon creation of a node, we don't know the type of it's children.

Ruben Bartelink
  • 59,778
  • 26
  • 187
  • 249
Can't Tell
  • 12,714
  • 9
  • 63
  • 91
  • 2
    Can you provide a concrete example? I'm having a very hard time to see how this can ever be the case... in your tree example, you'd just pass in the root of the tree as a single dependency. – Mark Seemann Dec 08 '11 at 18:59

2 Answers2

2

If the thing being passed in can't be determined at the point of creation, you need some form of Abstract Factory, though it is generally useful to draw the line between Services and Value Types that shouldnt have backreferences to to Services.

Why am I answering in generalities? Because you ask in generalities - please give an example of something more concrete and contextual you're looking for a good approach to if you really want to get an answer that's going to be useful.

You haven't specified whether you're looking at the Dependency Inversion Principle or DI Frameworks or Dependency management in libraries, which have as much in common and much to set them apart.

I suspect that (even though you don't seem to touch .NET tags), as @TrueWill has recommended, the excellent Dependency Injection in .NET book will help you to understand the subtleties involved (regardless of what language or platform you're using - the front of the book is just pretty technology independent patterns - to the degree that this is possible given that the excellent examples have realistic complexity levels means).

Community
  • 1
  • 1
Ruben Bartelink
  • 59,778
  • 26
  • 187
  • 249
  • So do we inject the Factory through the constructor of the class that depends on the objects created by the factory? – Can't Tell May 07 '12 at 04:28
  • Yes, that makes sense. You should really take the time to extend your question so you can get deeper advice - either by editing in an example or perhaps asking a new question if your understanding of your problem has changed. – Ruben Bartelink May 08 '12 at 08:00
1

Constructor injection is only one of various possibilities.

You can register your types in an IoC (Inversion of Control) container and resolve them when needed.

A .Net example with the Unity Application Block from Microsoft:

// When starting your application, you register your types:

var myContainer = new UnityContainer();
var logger = new Logger();
myContainer.RegisterInstance<ILogger>(logger);

// Later, when you need them, you can resolve them in your code:

var logger = myContainer.Resolve<ILogger>();
Dennis Traub
  • 50,557
  • 7
  • 93
  • 108
  • 2
    This example might lead the OP to pass around the IoC container, which is often seen as an antipattern. Normally you want to restrict the container to the [Composition Root](http://blog.ploeh.dk/2011/07/28/CompositionRoot.aspx). See [Dependency Injection in .NET](http://www.manning.com/seemann/). – TrueWill Dec 08 '11 at 16:39
  • 1
    Well, it could be combined with the Service Locator pattern (which is often considered and anti-pattern as well, I know.) I wanted to point OP to the fact that there's more possibilities of DI, not only constructor injection. – Dennis Traub Dec 08 '11 at 16:50