Dependency injection for tightly coupled components

Question

I am writing some code to parse some files (which I call "assets"), and I'm planning to structure this as three classes: AssetParser, NamespacesParser, and TransfomersParser. AssetParser will use objects of the other two classes to parse some parts of the assets.

I want to write this as three classes rather than one big class to split functionality into manageable fragments (that is I use something like structured programming, where methods of AssetParser call methods of the other two classes)

My question: Should I use dependency injection to create objects of NamespacesParser and TransformersParser classes?

The parts of the parser are tightly coupled to the parsers. In my opinion, it is highly unlikely that AssetParser would use other subparsers in place of NamespacesParser and TransformersParser. So it looks like that dependency injection is not necessary here. (I can just use new to create objects of NamespacesParser and TransformersParser.)

One reason to use dependency injection is that it allows easily make NamespacesParser and TransformersParser singletons (if I will want to use singletons). Are there other reasons?

Answer 1

DI is not an end in itself, it is a means to an end.

If changing the sub-parsers is (currently) not a goal for your final asset parser, the question you have to ask yourself is: can DI help by making unit testing easier?

So this boils down to a very simple decision:

• if you can think of a meaningful unit test where replacing the sub parsers by some mock objects will help you to test the asset parser in better isolation, then DI will make sense.

• if, however, you can write all the tests you need without DI, then it will not be required.

I should add that your idea about "using DI for making it easier to create singletons" sounds more like a reason against using DI: singletons are just a tool whose usage needs a justification on their own. Because of their global nature, lots of people consider them being an antipattern. So when in doubt if you need them, better avoid them.

Note when you put parts of the parser functionality into these sub parser classes and create the latter in the constructor of AssertParser, it will probably be easy to add DI later by some simple refactoring when it turns out you need it.