Loosen Up: Tame Your Software Dependencies for More Flexible Apps

2008-03-13 james 10 comments

My latest article just hit the web in the March 2008 issue of MSDN Magazine. Loosen Up: Tame Your Software Dependencies for More Flexible Apps takes you on a journey from a highly-coupled architecture, which we’re all familiar with, to gradually more loosely-coupled ones. First stop is the problems inherent in highly-coupled applications. To start solving those problems, I look to dependency inversion and service location. Next stop is poor man’s dependency injection and then a simple, hand-rolled inversion of control (IoC) container. From there, I look at the features provided by full-fledged IoC containers and use Castle Windsor as an example, along with some Binsor thrown in for configuration goodness. My goal was to help developers understand the benefits of dependency injection and IoC containers by showing them the problems solved at each stage of the journey.

A big thanks to Howard Dierking, MSDN Magazine editor extraordinaire, for his encouragement and not having an issue with using Windsor for the advanced examples. Thanks to Oren Eini for help debugging a Binsor configuration problem in one of the examples. And an especially big thanks to my spouse and two young sons for their patience while I was writing.

Thanks in advance for reading the article. I welcome your feedback and questions.

.NET General, Agile, Software Design none

#1 | Written by Paulio about 17 years ago. Reply

Hi James, interesting article but I’m not sure that I agree with the points made, but given you obviously understand the subject I’d like to discuss the issues with you. I do agree that it is a good goal to avoid highly-coupled designs. I also think that you may (or may not) strive to use pure OO techniques of abstract data types and therefore conclude that interfaces are the way forward. However, in the context of your article I’m not sure they’re relevant. I believe the main focus of your article is about maintenance including changes to the services and testing. Let me start with testing. I believe that an important goal of class/object design is to model the domain problem and to avoid putting in extra non-domain plumbing code. The idea of using fake methods and indeed interfaces purely for the reason of testing is wrong. That is why I prefer to use intercepting mocking frameworks such as TypeMock that do no require *any* changes to the classes to support the testing of them. For me it’s a simple premise, one line of unnecessary code is more complex and harder to maintain. That brings me onto my second point, ease of reading. The more indirection you put into code the harder it is to predict by reading the code, so again I dislike the idea of putting indirection everywhere. Personally I do use a Broker pattern for database access but that’s one specific service where a change is likely and the number of ways of accessing a data-source is many and therefore leads to poor coding practices. I also use it for areas that are likely to change such as rules. However, to suggest that every service would require frequent changing and that indirection would be a good solutions seems impractical if not wrong.

My biggest bug-bear with tightly coupled code is where changing a service requires changing many clients. Interfaces don’t provide a good story for solving this – hence why Microsoft have started to use more base classes. Sure they’re good for not breaking a client and forcing a change, but practically (esp. for in-house development) you don’t want a number of new vs old interfaces and you’ll refactor anyway so not a lot of benefit there. Or in Microsoft’s case you mark them as obsolete. Even if you do use an indirection technique as you suggest it might abstract away the concrete class (good thing) but you still have to refactor for the new interface. I.e. It doesn’t matter how configurable the concrete class is if you change the API you change all the clients, that’s where I believe the real issue is.

Thanks for the great read, please don’t think I dislike the article but this is an issue that I’ve struggled with for some time so I’m always interested in discussing possible solutions to it.
#2 | Written by James Kovacs about 17 years ago. Reply

To paraphrase Shakespeare… To use interfaces or not to use interfaces, that is the question.

If you’re using a mocking framework like Rhino Mocks or NMock, interfaces make mocking a lot easier. Yes, you can mock classes, but only if the methods/properties that you want to mock are declared virtual. So personally I stick to interfaces. TypeMock allows you to mock everything by leveraging the CLR Profiler API. That is good and bad in my opinion. It reduces noise in your code from extra interfaces, but you lose the "design barometer" provided by interfaces. If something is hard to test using Rhino Mocks, it usually indicates a problem with my design. I’m not going to open up the "TypeMock is too powerful" debate again. If I was walking into a legacy codebase with few unit tests and tight coupling, I would consider using TypeMock to introduce testability into the codebase. I would also be leaning heavily on Michael Feather’s dependency breaking techniques.

I should also say that I introduce interfaces opportunistically. I’ll use them for Services and Repositories, but not typically for domain objects unless I see the need. When I first started using interfaces this way, it seemed like extra noise, but I’ve found it relatively unobtrusive. ReSharper makes it incredibly simple to work with this type of structure because you can navigate to definitions, implementations, extract interfaces, push a method up to an interfaces, and much more all with a few keystrokes. Using interfaces is a matter of taste, IMHO.

Your bigger question is around versioning, which is a complex topic. NHibernate and Castle both rely heavily on interfaces, often with an abstract base class underneath. Microsoft is going the route of abstract base classes now with ASP.NET MVC. I still need to fully think through the implications, but in my experience with NHibernate and Castle through a few versions, I haven’t encountered major versioning headaches associated with interfaces.

Both interfaces and abstract base classes act as contracts. If I add a method to an interface and you’re implementing it, your code breaks when you try to compile against the new version. If you are concerned about this, derive from the abstract base class rather than the interface. The interfaces make mocking a lot easier and encourage looser coupling, since you’re coupled only to the method signatures and no implementation details.

As for versioning between clients and services – as you seem to be implying – you need to version your message contracts. WCF provides a nice way to use attributes on interfaces and classes to create WSDL and XSD, but you’re really versioning the messages on the wire. I would do this using data transfer objects (DTOs) to keep my wire-representation and domain model isolated from each other and independently versionable. If you don’t have the option of upgrading clients and services simultaneously, you have to keep old and new contracts available at different endpoints and gradually deprecate older endpoints as clients are upgraded. Your other option is to only allow backward-compatible, additive changes to your published message contracts.

Hope that helps and I would be happy to continue the discussion…
#3 | Written by Paulio about 17 years ago. Reply

I don’t have any strong opinions about if the use of Interfaces is good or not, like I say I think that is a different debate. What I strongly dislike is implementing something to pander to my test technology. However, I can see that IIF you make the choice of using Interfaces in your code, then having an Interface based testing technology is a positive advantage. However, my fundamental problem remains with the version arguments. Sure WCF is the way to go for cross process/domain comms and I could certainly see an argument that says, if WCF interfaces are good for cross process comms then why not use it everywhere you want a client to talk to a service (i.e. in the same domain). Now I think that is a good argument as it provides a great path for scaling out your solution. Although I still believe that you typically end up with lots of old obsolete code junk and end up refactoring. But…here I go again, I still do not see that it helps the main problem of coupling which is protecting code from change. How can I change a service without recompiling the client and it’s clients etc? I cannot see anything in dependency injection that helps resolve this. I can see how MS base classes help with this problem but there are a number of problems with this, not least the restriction of only one base class. Unfortunately I’ve yet to discover some utopian solution without going down the dynamic language route of discovering the methods each time the code runs.

I’ve not read Michael Feather’s book so I’ll look out for that.
#4 | Written by James Kovacs about 17 years ago. Reply

I used to be adverse to interfaces, but it’s become a non-issue for me. They add flexibility to my code and encourage loose coupling. Using ReSharper, it’s as quick to jump to the interface definition as the implementer(s) of that interface.

As for versioning… neither interfaces nor abstract base classes solve versioning despite claims to the contrary. Base classes suffer from the <a href="http://en.wikipedia.org/wiki/Fragile_base_class">fragile base class problem</a>. Base classes also leave you with less flexibility in implementation in single inheritance languages like C# and Java. (Multiple inheritance has its own share of problems. So that’s not necessarily a solution either.) Bothy interfaces and abstract base classes provide contracts. My personal preference is an interface (IFoo) and default base implementation in an abstract base class (FooBase). Then you have your choice of implementation strategies. You want stability and default behaviour – implement the abstract base class. You want full control – implement the interface.

Back to versioning… Within an application, you’re going to recompile anyway as the interfaces evolve. So no huge deal. The problem is at the boundaries. Messages coming into the system where you want to handle messages from new clients and old clients. Even with abstract base classes, if you add a new method, your client-side proxies aren’t going to know anything about them. So you’re back to recompiling the client. If you have only made additive changes (new classes and methods), it doesn’t matter whether you’re using abstract base classes or interfaces. Either way the received messages from new or old proxies will work. If you want true flexibility, you need to investigate XmlAny and similar constructs in your schemas. You have to make your messaging flexible and current tooling doesn’t support this very well. You’re left to splunk through the XML yourself, sometimes with your XmlAny elements as a hashtable of objects. This is an area where dynamic languages could assist. We’ll see what the future brings.
#5 | Written by Richard about 17 years ago. Reply

I don’t think the first sentence of your article makes much sense:
"Few would disagree that striving for a loosely coupled design is a bad thing."

Removing the double-negative, that leaves us with:
"Most [people] would agree that striving for a loosely coupled design is a bad thing."

The article is trying to show that a loosely coupled design is a *good* thing, so why would people agree that it’s a *bad* thing??
#6 | Written by James Kovacs about 17 years ago. Reply

@Richard – Maybe it’s a Canadianism, but the first sentence makes sense in my head. I wouldn’t have written the article if loose coupling was a bad thing. My intent was to show how a loosely coupled design can improve your architecture and how to achieve loose coupling using DI and IoC.
#7 | Written by Richard about 17 years ago. Reply

James,

I know that was your intent, and the rest of the article was very good, but the first sentence is definitely wrong. If "few would disagree", then "most would agree".

I would have used either:
"Few would disagree that striving for a loosely coupled design is a good thing."

or:
"Most [people] would agree that striving for a loosely coupled design is a good thing."
#8 | Written by Paulio about 17 years ago. Reply

The first sentence is fine, if only I had time to worry about things like that!
#9 | Written by peter about 16 years ago. Reply

Hi!
I was wondering how much different this is from what Jean-Paul Boodhoo has in his source code .???

both code are similar and I’m asking if this is a know pattern ?

thank you for great artickle
#10 | Written by James Kovacs about 16 years ago. Reply

Jean-Paul Boodhoo and I are good friends and we’ve learned a lot from each other over the years. So the similarities shouldn’t be too surprising. You’ll see similar ideas in Oren Eini’s Rhino Commons, Jeremy Miller’s StoryTeller and StructureMap, and many other places. The "pattern" – if you want to call it that – was recently pseudo-standardized in the Common Service Locator library on CodePlex.

http://www.codeplex.com/CommonServiceLocator

The library was a collaboration between many of the major IoC container authors. The intent is to enable framework vendors (including Microsoft) to start leveraging IoC in a standard way without binding to a particular container.

James Kovacs' Weblog

Recent Posts

Browse by Tags

Archives

Categories

Loosen Up: Tame Your Software Dependencies for More Flexible Apps

Leave a Comment