Notwendigkeit für Schnittstellen, Injektionen in einzigartigem Projekt

Question

Warum sollte ich Schnittstellen und Abhängigkeitsinjektion auf einer Website implementieren, ohne dass jemand anderes wiederverwendet oder ein Upgrade von jemandem eingeht?

Answer 1

Als Sie gelernt haben, wie man einen Computer programmiert, entwickelten Sie eine Art „Muskelgedächtnis“ Ihres Handwerks. Im Laufe der Jahre programmieren Sie weiterhin in derselben Denkweise. Die meisten Menschen lernen von Anfang an nicht alle raffinierten OOP -Prinzipien, daher scheinen sie mehr Mühe zu sein als die Art und Weise, wie sie gelernt haben.

Sie sollten sich an die Gewohnheit nehmen, OOP -Design -Techniken anzuwenden, wenn Sie eine OOP -Sprache verwenden, da Sie dies insgesamt zu einem besseren Entwickler machen. Ihr Ziel sollte es sein, Ihr Muskelgedächtnis an die Programmierung zur Verwendung dieser Techniken zu übernehmen. Dann müssen Sie diese Fragen nicht stellen und davon ausgehen, dass die Techniken irgendwie "im Weg" Ihrer Programmierung stehen. Sie werden ein Programmierer, der auf diese Weise nur programmiert.

Answer 2

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 3

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 4

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

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.