4

Is it safe to say that a Container is the "program" or mechanism that manages IoC via DI, but it doesn't really change your initial design of DI to accomplish loose coupling?

In other words, if I want to achieve loose coupling, say for a Logger, using a Container doesn't change that. It just manages it in case I had a lot of dependencies to construct a class (less typing, more manageable, better Unit testing, etc.)

It won't change the fact that I have interfaces and contracts with ILogger or IDatabase, for example, correct?

//Assume I have to interfaces and two classes that implement them
Class DemoDI
{
    ILogger myLogger;
    IDatabase myDatabase;

    DemoDI(ILogger myLogger, IDatabase myDatabase)
    {
        this.myLogger = myLogger;
        this.myDatabase = myDatabase;
    }

    //Methods that do stuff with the logger and database
}

I'm asking if that wouldn't change, that design pattern. It's just that somewhere, (main?), I would (say with Unity)

ioc.RegisterType<ILogger MyLoggingClass>(new ContainerControlledLifetimeManager());
ioc.RegisterType<IDatabase MySQLDatabaseClass>; //transient by default

And, if MySQLDatabaseClass had,

interface IDatabaseConnection
{
    void GetConnection();
}
Class DataConnection : IDatabaseConnection
{

    public void GetConnection()
    {
        //Get a connection
    }

}
Class MySQLDatabaseClass
{
    DataConnection myConn;

    MySQLDatabaseClass(DataConnection myConn)
    {
        this.myConn = myConn;
        this.myConn.GetConnection();
    }
    //Do other things;


}

Then the Container would wire that up too, assuming I had a:

ioc.RegisterType<IDatabaseConnection, DataConnection>();

If not I'd have to do it all by hand. The container is the helper that makes it nice and neat and assembles it all.

Now, if I want to Unit test the database class I would just have to adjust my container:

ioc.RegisterType<IDatabase MyMockedUpMySQLDatabaseClass>; //transient by default

Do I understand the purpose of an IoC Container correctly? Hopefully, I didn't get too lost in my dependencies.

  • 3
    If you're Doing It Right™, and it seems you are, then no; using an IoC container (or not) has no impact on the design of your code. – RubberDuck Dec 22 '16 at 22:32
  • 1
    Container won't change your design, but container itself doesn't imply auto wiring and mapping concrete classes to inetrfaces. You might be pushed into wrong decisions by these magic tricks (would you reject stupid decorator because it requires different approach?). A tendency to smear composition all over the code (annotations) might be unpleasant expierience either as your controll over it also becomes "inverted". – shudder Dec 22 '16 at 23:40
  • 2
    To concur with RubberDuck, if you're doing it right, a container changes nothing about the design of your code. But it's entirely possible to abuse a container to more tightly couple your application. – mgw854 Dec 23 '16 at 0:45
  • @mgw854 I was wondering about that as well. That configuration looked just as hardcoded as the other, at times. – johnny Dec 23 '16 at 2:49
  • 1
    Hard to recall something concrete - its sort of compiled source product. Though I can point you out to these two I came across recently: Mark Seemann - When to use DI container and Greg Young - 8 Lines of Code – shudder Dec 23 '16 at 10:08
6

Is it safe to say that a Container is the "program" or mechanism that manages IoC via DI, but it doesn't really change your initial design of DI to accomplish loose coupling?

IoC and DI will change any design that didn't previously follow them. Using a container shouldn't change your design but it often does. Some containers demand you spread knowledge of the container throughout your code base. You end up trading one one set of dependencies for another. You shouldn't be able to look at a class and tell what container is involved. If you can, well now you're dependent on that container.

IoC and DI do not require a management container. You can manage them best by understanding what they are rather than expecting a container to do your thinking. You can manage them with a container but that's your choice.

Foo foo = new Foo( new Bar() );

That right there is a dependency injection. Foo depends on Bar, or at least some kind of Bar like thing. Foo can't exist without it. Bar is a dependency. Since Bar is being passed to Foo, Bar is a dependency that's been injected.

IoC is a complicated way to say: don't hard code knowledge of an implementation. If Foo built it's own Bar, Foo would be hard coded to Bar and Foo couldn't accept new kinds of Bar but if Foo doesn't know about Bar, just an interface, then Bar can be changed without touching Foo.

There are many way's to not hard code a dependency (follow IoC):

  • Factory pattern
  • Service locator pattern
  • Dependency injection,
  • Constructor injection
  • Parameter injection
  • Setter injection
  • Interface injection
  • Contextualized lookup
  • Template method design pattern
  • Strategy design pattern

You can do this stuff in a container. You can do it in construction code. You can do it in main.

Wherever you do it, please don't mix this construction code with behavior code. Hard wiring together stuff the moment you feel like it creates the mess that started this overblown container movement in the first place. It's a real problem. The best solution is to understand that you can fix it yourself.

  • Doesn't the container become useful when there are many dependencies for Foo and many for Bar? I have the same thoughts about the Container. There is something in there I just don't like, like an ORM, but I can't say I won't use them. I do. I have to think on IoC Containers a bit. – johnny Dec 23 '16 at 16:30
  • 2
    IoC Containers are often abused to impose an architecture. It's a poor team that needs that. Sure Java makes construction a pain because it doesn't have named parameters. The josh bloch builder simulates them to take care of that. Hash tables let me find instances based on strings just fine. And I know how to not mix behavior classes with construction classes without being forced to do construction in xml. But sure, I can find a use for a container. They can automatically resolve the cyclic dependencies we shouldn't have designed in the first place. Whee... Fun... – candied_orange Dec 23 '16 at 18:02
  • You should add this to your answer. – johnny Dec 23 '16 at 18:09

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.