Dependency Injection: I don't get where to start!

Question

I have several articles about Dependency Injection, and I can see the benefits, especially when it comes to unit testing. The units can me loosely coupled, and mocking of dependencies can be made.

The trouble is - I just don't get where to start.

Consider this snippet below of (much edited for the purpose of this post) code that I have. I am instantiating a Plc object from the main form, and passing in a communications mode via the Connect method.

In it's present form it becomes hard to test, because I can't isolate the Plc from the CommsChannel to unit test it. (Can I?)

The class depends on using a CommsChannel object, but I am only passing in a mode that is used to create this channel within the Plc itself. To use dependancy injection, I should really pass in an already created CommsChannel (via an 'ICommsChannel' interface perhaps) to the Connect method, or maybe via the Plc constructor. Is that right?

But then that would mean creating the CommsChannel in my main form first, and this doesn't seem right either, because it feels like everything will come back to the base layer of the main form, where everything begins. Somehow it feels like I am missing a crucial piece of the puzzle.

Where do you start? You have to create an instance of something somewhere, but I'm struggling to understand where that should be.

public class Plc()
{
    public bool Connect(CommsMode commsMode)
    {
        bool success = false;

        // Create new comms channel.
        this._commsChannel = this.GetCommsChannel(commsMode);

        // Attempt connection
        success = this._commsChannel.Connect();  

        return this._connected;
    }

    private CommsChannel GetCommsChannel(CommsMode mode)
    {
        CommsChannel channel;

        switch (mode)
        {
            case CommsMode.RS232:
                channel = new SerialCommsChannel(
                    SerialCommsSettings.Default.ComPort,
                    SerialCommsSettings.Default.BaudRate,
                    SerialCommsSettings.Default.DataBits,
                    SerialCommsSettings.Default.Parity,
                    SerialCommsSettings.Default.StopBits);
                break;

            case CommsMode.Tcp:
                channel = new TcpCommsChannel(
                    TCPCommsSettings.Default.IP_Address,
                    TCPCommsSettings.Default.Port);
                break;

            default:
                // Throw unknown comms channel exception.
        }

        return channel;
    }
}

Related: http://stackoverflow.com/questions/4570750/dependency-injection-turtles-all-the-way-down/4570814#4570814 — Mark Seemann, Jan 03 '11 at 11:56
Did you read the dependency-injection tag intro/FAQ at http://stackoverflow.com/tags/dependency-injection/info — Mark Seemann, Jan 03 '11 at 11:59
On where to compose the application: http://stackoverflow.com/questions/1410719/design-where-should-objects-be-registered-when-using-windsor/1410738#1410738 — Mark Seemann, Jan 03 '11 at 12:00

score 1 · Accepted Answer · answered Jan 03 '11 at 11:50

1

Hard to answer such a broad question, but your specific question of where/who creates the connection object is simpler.

You could pass in a factory object that knows how to create connection objects as well as or instead of the mode. This way, if you want to create different (e.g. mock) connections you just pass in a different factory object that creates a different implementation of the connection when asked to create one.

Does that help, or did I miss the real question?

answered Jan 03 '11 at 11:50

DaveC

2,020
15
13

Thanks, that does help. OK, so a CommsChannelFactory... Do you mean have a factory that uses, say, an ICommsChannelFactory interface, then create a MockCommsChannelFactory with this interface when unit testing, which would then return a dummy ICommsChannel object? (Am I on the right lines here?!) – Andy Jan 03 '11 at 12:25
That sounds like the right line to me. It all comes down to how plugable an object/implementation is, but try to keep some balance or you will end up with an exponential explosion of interfaces and injection, which I've found can lead to hard to comprehend systems. – DaveC Jan 03 '11 at 12:42
'Hard to comprehend' I don't need :) This example seems like a natural place for an interface to separate the concerns and make testing easier, but I take your point. – Andy Jan 03 '11 at 12:57
1

The factory example we are discussing is the perfect place for an interface. The concern is where people over-do it to no real value and you end up with loads of tiny classes which can make the system hard to comprehend unless you fully understand the mental model that the designer had. So my advice is to use good tools and refactor mercilessly when you realise that you should have more injection rather than constantly scatter it everywhere you can. – DaveC Jan 03 '11 at 18:45
I have decided to refactor things to pass in ICommsChannel instances to the Plc that are produced from a separate factory. This will at least allow me to unit test the Plc with some mock ICommsChannels. I'll accept your answer because it got me thinking along these lines, thanks. – Andy Jan 04 '11 at 18:54

score 0 · Answer 2 · answered Jan 03 '11 at 12:37

What i would do.

Dependency Injections is something you sooner or later run into when applying the S.O.L.I.D principles, so instead of jumping right into the action take som time and read this excellent pdf.

http://www.lostechies.com/blogs/chad_myers/archive/2008/03/07/pablo-s-topic-of-the-month-march-solid-principles.aspx

And then checkout.

http://structuremap.net/structuremap/

For examples.

It was the best ride of my life, hope it will be an equaly thrilling experience for you.

Dependency Injection: I don't get where to start!

2 Answers2