Necessity for Interfaces, Injections in unique project

Question

Why should I implement Interfaces and Dependency Injection on a site with almost no chance for reuse or upgrade by anyone else?

Answer 1

Why, indeed?

I don't think interfaces and injection are only about reuse or upgrade.

Personally, I use interfaces and DI for all projects. It's not enough of an overhead to make avoiding them a benefit.

Answer 2

Because the assumption that you are making is the same assumption which resulted in Y2K.

Answer 3

It often makes unit testing quite a bit simpler. For example, you might have a type which uses another type which connects to a database. For unit testing the first type, you can inject a testing mock in place of the second type, allowing you to effectively unit test the first type without indirectly connecting to the database via the second type.

Answer 4

When you learned how to program a computer, you were developing a kind of 'muscle memory' of your craft. Over the years, you continue to program in that same mindset. Most people don't learn all of the nifty OOP principles right from the start, so they seem like they are more effort than the way they learned.

You should get in the habit of using OOP design techniques whenever you are using an OOP language, because that will make you a better developer overall. Your goal should be to retrain your muscle memory of programming to use those techniques. Then you won't have to ask these questions and assume that the techniques are somehow 'getting in the way' of your programming. You become a programmer that just programs that way.

Answer 5

I find that it makes it much easier to re-use my code in ways I haven't yet thought of. It also makes it easier to change how the code works without changing the source code.

I am using Spring.NET for dependency injection.

Let's say you have a Machine class which has a DoWork() function. Then you create a IWorkAlgorithm interface, with specific algorithm implementations for each machine.

Each instance of Machine has a IWorkAlgorithm injected into it, and Machine.DoWork() calls the injected implementation.

Now you have the following advantages:

1. You can swap in new implementations just by editing an XML file.
2. You can change properties of each implementation (timeouts, limits, etc.) by editing an XML file.
3. You can re-use your implementations outside of the Machine class.

Answer 6

If you are doing object-oriented programming, even if you're the only developer who will look at the code, you should still be unit testing, and that becomes complicated if you do not use dependency injection.

Don't forget that the "other developer" on your software can very well be you. You can hack together a mass of highly coupled, inter-dependent code that works, and even understand it while you're working on it, but the moment you step away from the project, even for a couple of days, you'll start to forget about all the little things that kept the ball of yarn from unraveling.

When you come back to it (and I have yet to see a piece of software that did not require some changes down the road), you'll wish you had followed all of the best practices.