This post originated from an RSS feed registered with .NET Buzz
by Udi Dahan.
Original Post: So many Dlls, so little time
Feed Title: Udi Dahan - The Software Simplist
Feed URL: http://feeds.feedburner.com/UdiDahan-TheSoftwareSimplist
Feed Description: I am a software simplist. I make this beast of architecting, analysing, designing, developing, testing, managing, deploying software systems simple.
This blog is about how I do it.
The other day, one of the leads on a project I'm architecting asked me why I insisted on "so many" dlls. In his opinion, increasing the number of "moving parts" would just make things more complicated. It wasn't the first time I was asked this question, so I thought I'd think it over a bit more this time.
I think that it's a reasonable and expected response. What's wrong with what we're doing now? How is dividing it up more going to make it better?
Before I get into the reasoning, the end result needs to be examined.
Have you ever had a case where you used a dll (let's call it A) which depended on B, which in turn depended on C. In your project/dll you also use C directly. I'd be willing to bet that almost everyone has run into this scenario. This is the path to dll hell, more appropriately named versioning hell. It is at the root of many an integration gone bad. Reminds me of the commercials "when you sleep with your friend, your also sleeping with all your friend's friends, and their friends..." and so on.
The hell above is the result of sloppiness. Sloppiness with dependencies. If two classes are independent of each other, and do not provide different implementations of the same interface, think twice about putting them in the same project/dll. Minimizing dependencies is the bread and butter of loose coupling. Break dependence on implementations by introducing interfaces in a separate project/dll.
Do it over, and over, and over again.
* You don't necessarily have to code, in order to refactor your design.
In the end, you should see bunches of projects/dlls which go together, while between the bunches there is almost no dependence whatsoever. The boundaries between bunches will almost always be an interface project/dll.
This will have the pleasant side-effect of enabling concurrent development of bunches with developers hardly ever stepping on each other's toes. Actually, the number of projects in a given developer's solution will probably decrease, since they no longer have to deal with all parts of the system.
Bottom line: design is about managing dependencies between classes and dlls.
Previous Topic
