One 17
I posted earlier about the three numbers of software design (zero, one, many). Zero and Many are numbers we see pretty often, but the rise of TDD has made “one” just a little bit lonelier. I wanted to say that one is the loneliest number, but David Chelimsky beat me to it several months ago, and I would just feel like a copycat.
When we’re test-driving an application into existence, we tend to create mock objects. The presence of one mock object in addition to one real object places is firmly in the design space of “many”, and so interfaces become the rule of the day.
In addition, we have dependency management to deal with. In order to reduce the D metric on a package, we find ourselves often breaking a class into an interface (increasing A) and an implementation that depends upon it (increasing I) in a separate package.
Of course, the “other question” is volatility. If we have one implementation of something small and simple in a domain that is very stable then we don’t need any interface and “one” takes center stage. This is true for whole value objects (fowler) in general. If the class is more complex, or dependent on special hardware or changing algorithms, then we end up creating a mock (driving us back to “many”).
But the number one is becoming more and more rare in our design world.
Trackbacks
Use the following link to trackback from your own site:
http://blog.objectmentor.com/articles/trackback/5209
” ... we find ourselves often breaking a class into an interface (increasing A) and an implementation that depends upon it (increasing I) in a separate package.”
Which also means making the interface public, though the original class may have been package-private.
Hope you’ve a good hierarchical encapsulation strategy to limit the damage …
Sounds like someone is thinking in Java. I’m a long-time OO developer (since at least 1988) and have quite a bit experience as a professional developer (since 1979), but I only decided to stop avoiding the inevitable and start trying to learn Java last year. I’ve yet to learn to like it, and have not fully internalized it. It’s still a foreign language to me, so please forgive me when it shows.
But if I were breaking up a package because of D, then it would be with the intention of splitting the interface and implementation among different physical packages (whether across logical packages or not). Yes, it could have such a drawback.
Thanks for pointing that out! It might save someone some trouble in the future.
Hej, Tim,
Yes, you’re quite correct: I’m a Javaist.
When I read your article above, something else struck me, but I wasn’t sure what it was till I went away and slept on it. This morning, it surfaced to consciousness: “In order to reduce the D metric on a package …”
I enjoy studying the D-metric as much as the next man, but I hadn’t really given serious consideration to attacking structure with the sole intention of reducing D (not that you were full-heartedly proposing that). I usually work to design rules that have steered me well in the past and at the end, take a peek at D just to make sure I’ve not drifted into turbulent waters.
D is something I tend to see in the rear-view mirror (to mix metaphors).
Even when I study the works of others with an eye to refactoring, I look at D as being a symptom of a structural disease rather than an attack vector.
I like the idea, but I can imagine there are cases where a reduction of D would seem a local improvement, but on the global scale of the application’s structure, it might not look so rosy.
I mentioned the structure of jBehave on another mentor blog, and I’ll use it here as an example. As I mentioned before, jBehave has a beautiful structure: it has a lovely curve, indicating a hierarchy of behaviour of which I wholely approve. Here’s a picture of it, but colour-coded for D: the redder, the larger the D:
http://www.edmundkirwan.com/jbehave-d.png
A few packages have a D of 0.75 or 0.8, but only one has a D of 1.0: org.jbehave.core.exception package. If we ignore the nastiness of Java’s forbidding abstract exceptions, it might seem like an improvement to attack this package’s D-value and start splitting out interfaces: and in general I would approve. But this package does nicely encapsulate all the application’s exceptions: it would be a shame to reduce its D only to sprinkle these exceptions throughout the structure, rather than have them nicely concentrated where they are.
Of course, we could argue that we can reduce its D value and still maintain encapsulation of the exceptions: I’m sure it would be possible; I suppose I just want to acknowledge the constraint of keeping an eye on the overall structure while we are busy working on any single package’s D metric.
Just for fun, here are two more pictures of jBehave, the first colour-coded for A:
http://www.edmundkirwan.com/jbehave-a.png
And this colour-coded for I:
http://www.edmundkirwan.com/jbehave-i.png
Finally, though I admit to being profoundly fascinated by examining the structure of applications, I’ll also admit that the first test of any software is its utility: if it does the job you want and does it well, then its structure is almost irrelevant. I think no software demonstrates this better than jUnit.
jUnit is a masterpiece of utility, but its structure is almost indecipherable: a double-hump of seeming duplication and unintuitive package names. OK, I admit to reading in all the classes here, but the sentiment persists. Here’s a picture showing its 7 circular dependencies (I suppose no tool is perfect):
http://www.edmundkirwan.com/junit.png
I do enjoy your blog, by the way.
.ed
With which tool did you create these diagrams?
http://www.edmundkirwan.com/servlet/fractal/GetFrac
I don’t remember the “one is the loneliest number” reference. Can you refresh my memory?
one is the loneliest number” reference. Can you refresh my memory?
Even when I study the works of others with an eye to refactoring, I look at D as being a symptom of a structural disease rather than an attack vector.
By making the system cleaner and smaller, we were being reported as making negative progress, and were ordered to stop!
legitimate stainless, where by the earlier knives could well be even more stain less than stainless while in the modern day sense.
Actually this site is very nice and informative. Thanks
Tüm dunyadaki okey oyunculari ile ayni platform içerisinde sohbet ederek canli okey oyunu oyna ve ve internette online oyun oynamanin zevkini çikar.
These blog are new and very good.
Actually this site is very nice and informative. Thanks
It’s a useful blog.I would like to know how you develop the applications.thanks.
Basically no other RC Monster Truck sorts of knowledge was first attainable to the lawsuit.
It is nice of you to post this.I will pay more attention on it. Discount designer Men DSQ Jeans from China at on line store
This is really good idea. why not keep a copy of the iPhone data on computer without iTunes and you can restore the file to iPhone when necessary. good luck.