Too Many Interfaces
Jan 20 2010 09:58 PM Filed in: Personal
While writing some code at work the other day, I
noticed something, that I had meant to blog about
earlier.
I work in a .NET development shop, coding C#. One of the latest kicks we’re on at work is IOC and Dependency Injection, we use it everywhere. It’s almost a crime if you actually create an instance of an object using the ‘new’ keyword. One of the side effects of this is we have interfaces for just about everything. There are a couple things I don’t like about this.
When I think of interfaces, I generally think of the something along the lines of IDisposable, IView, INotifyPropertyChange, IDraggable, etc. These interfaces are something you implement if you need certain functionality, and they can be used by multiple classes in your projects. When you start creating interfaces for every class in your project so that you can use a service locator or some other means to create the concrete instance of the class, you end up with interfaces named IUpdateAddressView, IContractService, ILinearScheduleRepository, etc. You’re not going to have any class except for LinearScheduleRepository implementing the ILinearScheduleRepository interface, it’s specifically made for that class, so that you can write code like this
It adds complexity and it also makes navigating to code a pain in the arse, unless you have a tool like Resharper at your disposal. If you don’t and you right click on a method or property and chose to go to the definition, you end up in the Interface, not the class that implements that interface method or property.
My other gripe with this is you end up feeling like you’re coding in C/C++, where the interfaces are the equivalent of header files. You can no longer add a new method or property to a class, you must first go to the interface for that class and add your method or property there, then you can go to the class and implement it. It’s a pain to always have to remember to do that, since that’s not something you would generally have to do in C#. I don’t really like having to code for some tool that we’re using. Another place we do this is having to occasionally mark a method as virtual, so that our Mocking tool doesn’t call it when recording your expectations. There’s no other reason for that method to be virtual, but we have to do it if we want to Mock a test (which is something else I’m really not a fan of, but I will save that for another post).
I can see some benefit in IOC and Dependency Injection, I guess it’s just a case of the usual going overboard on the latest buzzword/development craze that we tend to do at my work. Maybe one of these days we’ll go the “let’s try and do a nice simple, non complex” implementation, the kind of thing I enjoy, but I doubt it. I can already sense that our next project will be Silverlight with Prism, Entity Framework, and some Fluent and maybe automapper thrown in just for fun.
I work in a .NET development shop, coding C#. One of the latest kicks we’re on at work is IOC and Dependency Injection, we use it everywhere. It’s almost a crime if you actually create an instance of an object using the ‘new’ keyword. One of the side effects of this is we have interfaces for just about everything. There are a couple things I don’t like about this.
When I think of interfaces, I generally think of the something along the lines of IDisposable, IView, INotifyPropertyChange, IDraggable, etc. These interfaces are something you implement if you need certain functionality, and they can be used by multiple classes in your projects. When you start creating interfaces for every class in your project so that you can use a service locator or some other means to create the concrete instance of the class, you end up with interfaces named IUpdateAddressView, IContractService, ILinearScheduleRepository, etc. You’re not going to have any class except for LinearScheduleRepository implementing the ILinearScheduleRepository interface, it’s specifically made for that class, so that you can write code like this
var repository =
ServiceLocator.Create<ILinearScheduleRepository>();
It adds complexity and it also makes navigating to code a pain in the arse, unless you have a tool like Resharper at your disposal. If you don’t and you right click on a method or property and chose to go to the definition, you end up in the Interface, not the class that implements that interface method or property.
My other gripe with this is you end up feeling like you’re coding in C/C++, where the interfaces are the equivalent of header files. You can no longer add a new method or property to a class, you must first go to the interface for that class and add your method or property there, then you can go to the class and implement it. It’s a pain to always have to remember to do that, since that’s not something you would generally have to do in C#. I don’t really like having to code for some tool that we’re using. Another place we do this is having to occasionally mark a method as virtual, so that our Mocking tool doesn’t call it when recording your expectations. There’s no other reason for that method to be virtual, but we have to do it if we want to Mock a test (which is something else I’m really not a fan of, but I will save that for another post).
I can see some benefit in IOC and Dependency Injection, I guess it’s just a case of the usual going overboard on the latest buzzword/development craze that we tend to do at my work. Maybe one of these days we’ll go the “let’s try and do a nice simple, non complex” implementation, the kind of thing I enjoy, but I doubt it. I can already sense that our next project will be Silverlight with Prism, Entity Framework, and some Fluent and maybe automapper thrown in just for fun.
|