3

To learn dependency injection in a current side-project, I am writing my own dependency injection container.

But this has lead me to wonder, at what point is it worthwhile to use a third party product vs "roll my own"? What would be the kind of questions you would ask to figure this out?

  • Is your question about tools in general, or about dependency injection specifically? The DI question has an answer; the answer to the general question is "it depends." – Robert Harvey Mar 20 '14 at 18:11
  • Tools in general. It seems like an important step in the growth of a software developer is knowing when to roll your own vs using a tool. – Zeroth Mar 20 '14 at 18:12
  • Like most other things in software development, it depends. You evaluate your specific software requirements, and then decide whether or not tools or custom development best fits those requirements. – Robert Harvey Mar 20 '14 at 18:12
  • I guess I was curious what kind of knowledge there might be out there, best practices, learnt from pain to figure this out. – Zeroth Mar 20 '14 at 18:14
  • 1
    possible duplicate of Reinventing the Wheel, why should I? See also: What counts as reinventing the wheel? – gnat Mar 20 '14 at 18:19
3

To really understand a tool, I do like to create my own version of said tool. It helps me understand what the tool is actually doing and the hard parts of the problem it is trying to solve. Understanding those things can help you make better decisions about how to use the tool.

That being said I would rarely recommend using the roll-your-own over the tool in a real project. A few reasons for this are:

  1. Your version has only had you use and test it
  2. It's hard to hire people that have knowledge of your custom tool
  3. You're the only person who can fix it if there's a problem
| improve this answer | |
2

The "buy vs build" decision comes down to a number of factors. Can you maintain the tool that you are buying (even if it's open-source)? Is there adequate support for it, if you run into a problem? Do you have the resources to build it yourself, and are you smart enough to generalize it so it can be reused in a variety of scenarios? And so on.

Regarding dependency injection: DI containers are not needed for most applications. Unless your application is a large, enterprise-type application, you don't need a DI container, and if you do need one, there are a number of containers already available that would serve the purpose well.

Smaller applications benefit more from a simpler form of DI, like injecting your dependencies directly through the constructor methods of your objects. You would only use a DI container if you needed to provide a central place to manage your dependencies in, say, an XML file describing them.

In the vaguest of terms, there is a "rule of three." If you find yourself doing the same thing three times in a software application, you either refactor it into its own tool or method, or find an off-the-shelf tool that replaces those three things with one generalized thing. Knowing when to do this comes with experience.

| improve this answer | |
1

Weigh time constraints versus specific project needs. Does the tool do exactly everything you need it to, or is it worth the extra x amount of hours required to complete your custom solution?

If this is a group project: Licensing cost. Is there room on your departments budget to afford allocating resources towards developing an in-house solution? Internal projects take a long time - and therefore cost money.

| improve this answer | |

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