Dependency Injection and code maintainability

I am working on a (vb.net/asp.net) project that is using interfaces to provide dependency injection. But to me, it feels like the maintainability of the code has been killed. When I want to read through the code, I can't simply jump to the code of a related class that is used. All I see are the interfaces, and so I have to hunt through the project to figure out what classes are doing the implementation. This really hurts my productivity.

Yes, I know I now can implement the interfaces with a wide variety of replacement classes. But for example, I know I'm not changing my data source any time soon--there is no need for me to enable the ability to swap that out. All of this dependency injection seems like overkill to me (in fact, the only real reason it is there is to support mock classes for unit testing). I've actually read several places that state DI is actually better for maintainability. But that assumes you already know where everything is and you know which class you need to update. Finding out where to look is the part that is killing me.

So, my question is: Is there a better way to traverse through the code? Is there a better way to make the code more maintainable? Are we just doing it wrong? Or is this par for the course?

There is definitely some overhead to DI, especially when your configuration is separated from your code. While this is par for the course, it does get easier to deal with over time, and as you get a better understanding of the code.

However, there is tooling that can help - Have a look at Resharper or CodeRush. Both offer excellent improvements to the code navigation experience in Visual Studio. Resharper has excellent "Go To Symbol" or "Go To Implementation" methods that quickly help you navigate to the implementation of your interface, wherever it may be.

To the point about maintainability: In general, a loosely coupled design becomes more important as time passes, because there will be change. The more tightly coupled your code is, the harder it is to make small changes without affecting the overall application. This is where depending on interfaces is very very important -- whether or not you choose to use Dependency Injection.

I guess this is where I don't see the advantages of modifying a class that implements your interface rather than modifying a concretely referenced class. Interfaces allow for multiple implementations, it doesn't necessarily allow an implementation change to be encapsulated.

JLX 2010-10-30 06:10:32

It does help, but maybe not in your application. If all your interfaces always expose exactly the same set of behaviours as your implementations, then yes, there's little difference between the implementation and interface. Interfaces per se do not magically improve your design, they are just a necessary tool when designing loosely coupled components.

Nader Shirazie 2010-10-30 21:03:00

Also, if you cannot understand the code you're working with without going into the implementation of the interface, then that's a different issue. For eg, I know that IList has an `Add` method -- if, when using a class that implements `IList`, I need to know how `Add` is implemented, then my class is dependent on the _implementation_ of `IList` rather than the `IList` interface. Designing components so that they do not have this type of dependency on implementation is what is important. That is what allows you to make changes to your app safely

Nader Shirazie 2010-10-30 21:05:56

ansaurus

tags:

views:

answers:

Dependency Injection and code maintainability

related questions