How to convert this code so it now uses the Dependency Injection pattern?

Question

Ok, So I have the following situation. I originally had some code like this:

public class MainBoard {
    private BoardType1 bt1;
    private BoardType2 bt2;
    private BoardType3 bt3;
    ...
    private readonly Size boardSize;

    public MainBoard(Size boardSize) {
        this.boardSize = boardSize;

        bt1 = new BoardType1(boardSize);
        bt2 = new BoardType2(boardSize);
        bt3 = new BoardType3(boardSize);
    }
}

Now, I decided to refactor that code so the classes' dependencies are injected, instead:

public class MainBoard {
    private IBoardType1 bt1;
    private IBoardType2 bt2;
    private IBoardType3 bt3;
    ...
    private Size boardSize;

    public MainBoard(Size boardSize, IBoardType1 bt1, IBoardType2 bt2, IBoardType3 bt3) {
        this.bt1 = bt1;
        this.bt2 = bt2;
        this.bt3 = bt3;
    }
}

My question is what to do about Board Size? I mean, in the first case, I just passed the class the desired board size, and it would do everything to create the other kinds of boards with the correct size. In the dependency injection case, that might not be more the case. What do you guys do in this situation? Do you put any kind of checking on the MainBoard 's constructor so to make sure that the correct sizes are being passed in? Do you just assume the class' client will be responsible enough to pass the 3 kinds of boards with the same size, so there is no trouble?

Edit

Why am I doing this? Because I need to Unit-Test MainBoard. I need to be able to set the 3 sub-boards in certain states so I can test that my MainBoard is doing what I expect it to.

Thanks

Answer 1

I would say the boardSize parameter is unnecessary in the second case, but I would add an assertion to ensure that the 3 board sizes are really equal.

But overall, the second case seems dubious to me. I would suggest the first approach, unless you really really need to inject different kinds of boards to the main board. Even so, I would consider using eg a board factory instead of passing 3 board parameters to the constructor, eg

public interface IBoardBuilderFactory {
    public IBoardType1 createBoardType1(Size boardSize);
    public IBoardType2 createBoardType2(Size boardSize);
    public IBoardType3 createBoardType3(Size boardSize);
}

This would ensure the consistency of the 3 boards regarding both "board family" and size.

We should know more about the context / domain model, specicifcally the relationship of the main board and the child boards in order to decide whether or not DI is the right choice here.

Answer 2

It is questionable whether Dependency Injection (or Dependency Inversion) should be applied in this case at all. It appears to me that your MainBoard is responsible for managing the lifecycle of the BoardTypes it created in the first sample. If you now do inject your BoardTypes this responsibility must be handled by the consumers of MainBoard .

It is a tradeof between flexibility and additional duties on the consumer side.

On the other hand, if it is sensible to have the lifecycle of BoardType s be handled externally , it is fine to use Dependency Inversion. Your constructor on MainBoard then needs to ensure it's dependencies are properly statisfied . This would include checking that their Size is equal.

Answer 3

The main advantage of dependecy injection is the insulation from changes to the objects being injected. So in your case the one variable apparent is the size. You would inject the boards into the main board so that the main board no longer needs to know or worry about the size. Also, unless your application needs to maintain 3 distinct behaviors between the different board types I would suggest using a single abstract definition for the board type interface.

public class MainBoard {
    private IBoardType bt1;
    private IBoardType bt2;
    private IBoardType bt3;

    public MainBoard(IBoardType bt1, IBoardType bt2, IBoardType bt3) {
        this.bt1 = bt1;
        this.bt2 = bt2;
        this.bt3 = bt3;
    }
}

It becomes the responsibility of the thing that does the injection (injection framework or assembling code) to ensure these boards are given the proper size. This can be done in a number of ways one example being the main board and injected boards all derive their size from a single external source. Maybe your app, in this case, sizes the injected boards relative to the main board.

So you could have external logic such as:

public class BoardAssembler {
   public static MainBoard assembleBoard(Size size) {
      Size innerBoardSize = deriveSizeOfInternalBoards(size);
      return new MainBoard(new BoardType1(innerBoardSize), new BoardType2(innerBoardSize), new BoardType3(innerBoardSize));
   }
}

Essentially what you're after is the inversion of the construction logic wherever MainBoard is constructed. Start there and extract everything into a factory or some evil singleton factory or static method. Ask yourself, "where is the MainBoard created?" Also ask, "what compoenents and parameters are needed?" Once you've moved all the instantiation logic into a factory it may become simpler to maintain Mainboard and all of its dependencies.

Answer 4

What type of info does the BoardTypeX class contain? Does it make sense to have this object injected into your MainBoard. Dependency-Injection, and patterns in general, is not always the solution, and you shouldn't use it just b/c you can. A factory patter of sorts may work better here

public class MainBoard {
    private IBoardType1 bt1;
    private IBoardType2 bt2;
    private IBoardType3 bt3;
    ...
    private Size boardSize;

    public MainBoard(IBoardBuilderFactory factory) {
        this.bt1 = factory.buildBoard(boardSize);
        //...
    }
}

And if the board size should be determined externally, maybe you don't store it at all. Maybe the factory determines what board size to use when it is constructed elsewhere.

Anyway, the point is, design patterns are there to help you accomplish tasks in a clean and maintainable way. They are not hard and fast rules that must be followed

Answer 5

-EDIT- Deleted most of my response because others beat me to it :)

Another option - factories. Depending on your requirements, you might find it better (or not) to use factories to solve your problem. There is a good SO discussion here about Factories Vs DI. You could even consider passing a factroy via DI into your class constructor - so your constructor takes a size and a factory class, and defers to the factory class (passing in the size) to get the boards.

Answer 6

You could get the boardsize from one of Boards that are passed along through DI. This way you could loose the boardSize variable alltogether.

Answer 7

You could have a BoardTypeFactory that creates BoardTypes like so:

IBoardType bt1 = BoardTypeFactory.Create(boardSize);

Note that there are tons of blog posts and SO answers on how best to write a factory, the above is a simple example.

You can then call

new MainBoard(boardSize, bt1, ....

passing the source size which was used to create the boards.

Answer 8

Within the scope of MainBoard , the boardSize is effectively a constant. You only want a single value of it to exist. You need some code like this:

int boardSize = 24;  // Or maybe you get this from reading a file or command line
MainBoardScope mainBoardScope = new mainBoardScope( boardSize );

If you naively made 24 a global or a constant you would have hard-to-see dependencies here because classes would rely on picking up that constant or global statically, rather than through a declared interface (ie. the constructor).

The mainBoardScope holds "singletons" for a group of objects that have the same lifetime. Unlike an old-school singleton, these are not global and are not accessed statically. Then, consider this code that runs when starting up your application (or this scope, in a larger application) to build the object graph:

   MainBoardFactory factory = new MainBoardFactory( mainBoardScope );
   MainBoard board = factory.createMainBoard();

Within that createMainBoard method, you would use the boardSize from the scope to create the three subboards:

   IBoardType1 b1 = injectBoardType1( myScope );
   IBoardType2 b2 = injectBoardType2( myScope );
   IBoardType3 b3 = injectBoardType3( myScope );
   return new MainBoard( scope.getBoardSize, b1, b2, b3 );

Do you need MainBoard to check each of the three boards passed to the constructor are correctly sized? If it is your code creating the boards, then create a unit test for injectMainBoard() . It is not MainBoard's job to ensure it is constructed correctly. It is the factories job to create it, it is the unit test on the factory's job to check it is being done right.