2

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?

Improve this question
6
  • What's about defining a provider of NamespacesParser (in order to easily switch between factory provider and singleton provider), but call the provider directly from AssetParser instead of dependency injection (because I find no reason to use dependency injection)?
    – porton
    Feb 14, 2018 at 19:21
  • 1
    Why are there three separate classes instead of all the code being in the AssetParser class? Are you writing all three classes at the same time? The answers to that might be relevant to the answer, so I'd suggest answering by editing your question rather than as a comment.
    – bdsl
    Feb 14, 2018 at 20:13
  • @bdsl I write three "separate classes" 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). I am going to write all three classes now. Dear bdsl: I do not quite understand your questions. Is this comment a good answer?
    – porton
    Feb 14, 2018 at 20:45
  • 2
    You could use depedency injection through constructors. There is no need to always use some type of container to do your depedency injection.
    – Nick Polyderopoulos
    Feb 14, 2018 at 23:46
  • 1
    @porton Another reason for DI is that humans are bad at predictin the future, as in "In my opinion is highly unlikely that X would happen."
    – Stop harming Monica
    Feb 15, 2018 at 7:11

1 Answer 1

Reset to default
7

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.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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