Sorry for reopening this old debate, but I have been struggling with getting my head around this concept but came to a conclusion of my own.

The problem

I build lots of websites and in work we have our own internal CMS engine that works the way we work.  It has the following (simplified) structure:

WebUI—–¬
|               |
Services—-|—-Entities (used in both WebUI and Service layer)
|
Data

Now everything I have read lately pushes me to programme to an interface – including my data layer “just in case some random person brain farts that we should change to MySQL” (this will never happen as I make the decisions).  If I were to program to an interface the 20 or so plus classes would each have their own interface, the 30+ entities would each have their own interfaces, and I would have SO much code, that I would no longer know what am doing e.g.

ICMS_PageService service = new CMS_PageService();
service.FetchById(id);

And I have seen code like that.  Or the FactoryPattern:

ICMS_PageService service = new SiteFactory().FetchPageServiceInstance(); // or whatever it was called
service.FetchById(id);

which is more understandable, in that you now only have 1 place to change the implemenation – so change the CMS_PageService implementation, update the SiteFactory as required, and your whole site continues to work as normal.  I get that, I quite like that in some respects.  What I don’t get is the IList vs List stuff.

Listing about

I read in another blog post:

“I already had cases where one returned a List as IList. But because of the IList interace I could not sort the result directly.”

Yeah, that’s annoying.  If say I have this:

ICMS_PageService service = new SiteFactory().FetchPageServiceInstance(); // or whatever it was called
IList<ICMS_Page> pages = service.FetchAll();

I cannot use pages as I would expect.  I want to pages.ForEach(page => stringBuilder.Append(page.Title)); Instead with IList I have to cast and muck around to get the same result (not that much more but enough to make the .ForEach a pointless addition if we all programmed to an interface).

Unit Test and Mocks

But I also understand that if you do programme to an Interface then you can easily test your code, someone else can mock things up, and you can make sure your whole code base is working dead simple.  But to me, that’s over kill for most things but complicated web/desktop apps – but take the idea of interfaces seriously if it’s complicated beastie you are working with.

Chisel vs Pneumatic Drill

So then, maybe my point is “right tool right job”?  If you are creating simple applications, that live and die real quick, say within a year or 2, then is there a need to add an extra few days/weeks doing all this overhead?  But with large apps that will take a year or 2 to build, then it might be more important.

Also if you have a strong code base that you have built up over time, that you know works, but doesn’t programme to an interface, should you retro fit things?

Everything I read screams at me to Unit Test, Mock, Programme to Interfaces, and all the reasonings are to make it easier to change things when requirements change…so ask your self before you listen to all of them, do you expect to move away from SQL Server?  Do you think that the changes in requirements are going to be so game changing that there is a need to make everything an Interface – which in most cases will cause you just as much problems e.g. add a new field in the CMS_Page table, will require a chance in the concrete CMS_Page class and the ICMS_Page interface before you will have access to the property in the WebUI.  Bit too much work for my liking.  Or if you add a new method to the CMS_PageService you have to do that to the interface as well, before it’s usable.  And if you have a lot of people using the interfaces elsewheres, and you change it, then you break lots of people’s code.  Conversely by not using Interfaces so often, or using them in a generic smart way, then adding a new method won’t break much of your existing code, the new method or property will just appear ready to use.

So use IList and have to cast and convert often in your code, while not getting access to the lovely new features in the generic List object.  Or use the List object, make a lot of purists angry but work the way you expect things to work.

Conclusions

So my conclusion is to use interfaces smartly and sparsely, if you are building a small to medium website.  But if a large app that will take years to build with tonnes of developers, then the use of interfaces in such a way maybe be warranted, locking down what code can do with your data.  But I would love someone to tell me, without using the “if things were to change due to client requirements” arguement, why I should use Interfaces all over the place in every project…