Object Mentor Blog: One

One

tottinger — Wed, 21 Mar 2007 09:17:00 -0500

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.

"One" by cathy

Fri, 09 Sep 2011 23:36:57 -0500

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

"One" by hi good luck

Mon, 29 Aug 2011 04:18:20 -0500

Basically no other RC Monster Truck sorts of knowledge was first attainable to the lawsuit.

"One" by Mens Leather Boots

Tue, 12 Jul 2011 21:41:02 -0500

It’s a useful blog.I would like to know how you develop the applications.thanks.

"One" by best mmo 2012

Thu, 16 Jun 2011 05:42:19 -0500

Actually this site is very nice and informative. Thanks

"One" by beats by dr dre headphones

Fri, 03 Jun 2011 00:37:22 -0500

These blog are new and very good.

"One" by okey oyunu oyna

Mon, 25 Apr 2011 10:14:34 -0500

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.

"One" by Nike Frees

Mon, 28 Feb 2011 00:29:06 -0600

legitimate stainless, where by the earlier knives could well be even more stain less than stainless while in the modern day sense.

"One" by Tenant Screening

Tue, 22 Feb 2011 11:25:12 -0600

By making the system cleaner and smaller, we were being reported as making negative progress, and were ordered to stop!

"One" by Criminal Records

Mon, 21 Feb 2011 14:14:50 -0600

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.

"One" by M2TS File Converter

Wed, 28 Apr 2010 22:59:31 -0500

one is the loneliest number” reference. Can you refresh my memory?

"One" by David Chelimsky

Sat, 24 Mar 2007 07:43:52 -0500

I don’t remember the “one is the loneliest number” reference. Can you refresh my memory?

"One" by www.EdmundKirwan.com

Sat, 24 Mar 2007 07:24:43 -0500

http://www.edmundkirwan.com/servlet/fractal/GetFrac

"One" by Tim

Fri, 23 Mar 2007 14:04:15 -0500

With which tool did you create these diagrams?

"One" by www.EdmundKirwan.com

Fri, 23 Mar 2007 12:52:17 -0500

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

"One" by tim

Thu, 22 Mar 2007 11:59:14 -0500

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.

"One" by www.EdmundKirwan.com

Thu, 22 Mar 2007 11:00:57 -0500

” ... 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 …