An interesting posting in the
comp.object newsgroup caught my attention this week. John Carter
brought up a nice metaphor about how unexperienced developers
would implement new requirements into an existing design. The result is
often a design we call Big Ball of Mud.
"So the dog has been built and a new requirement comes in...
If you stand on the dogs tail, it must yelp and scrabble away.
So what does Joe Average Coder do?
Open up the Tail.cpp, #include "AudioOutput.hpp" wire Dog to Yelp when the tail has been stood on.
He then #include's "LegControl.hpp" and begins to try to work out how the Tail can get the Dog to run..."
In a follow-up post John explains in more details the background of the story.
"The
correct answer in designing a Dog, of course, is the tail merely needs
to send an "Ouch!" signal to primary control object (brain) and there
after The Right Thing happens.
However a common
anti-pattern in software is to implement requirements starting from
input event, and since creating new software couplings are "free", to
access the control elements directly from the inputs. ie. In software,
the "Tail" module can trivially access the leg control module and the
"Tail" developer can get himself bogged down trying to write a "make
legs run" routine.
In hardware and Canines connections
(wires / nerves) are expensive so there is a natural conservatism about
creating additional coupling. In Software it's just another #include
and a name reference so developers will often gratuitously create
additional coupling, since the cost of doing so is borne in maintenance
not development.
The correct solution is given by the OOD concepts of Single Responsibility / Data Ownership / Law of Demeter / Tell Don't Ask.
So
now you know the full story, and next time you see someone hugely
violating the Law of Demeter you can briefly and pungently say, "Your
tail is trying to teach the Dog to run."
Of
course, I made the same mistake in implementing new requirements this
way. The resulting Big Ball of Mud design becomes a pain when it comes
to maintaing and extending the system. The time you save when you don't
care about the design will never pay off.
The bad news is that
most developers will be making this kind of mistake a couple of times
before they realize their poor decisions. Having said this I recommend
you study the OOD concepts that were referred to: