What’s
in a name? Plenty, when it’s ‘customer_name’ in a piece of
object-oriented programming that violates the Law of Demeter and forces
tight coupling rather than the loose coupling that everyone is striving
for nowadays.
Dovetail Software engineer Yi Wen finds an
affront to logic spelled out in a method called ‘customer_name’
belonging to an object called ‘order’. Yi says this leads to the order
knowing too much about the customer, which is an unneccessary
complication, a forced coupling of attributes that don’t need to be
coupled. See Law of Demeter and Forwardable
Yi
is using an example from an excellent post by Dan Manges illustrating
in lay language the overhead burden that comes from violating the Law
of Demeter, which Manges explains.
To be fair, Dan’s post
uses the name in a view, not a model – and gives the warning not to
model from views: a view is just a representation of the results of
logic, and rather like a Hollywood view of reality, shouldn’t be taken
as a model of the real logical process.
Dan Manges writes
about a difficult concept to grasp, and describes some tenets of
object-oriented programming in terms of the newspaper boy, the
customer, and the customer’s wallet.
“We want our paper boy to know as little as possible
about the customer. It’s okay for the paper boy to know the customer
has a method available to pay him. The paper boy knowing the customer
has a wallet (and even further, that the wallet has cash), is not okay.
This is what the Law of Demeter is about.” – Misunderstanding the Law of Demeter
We could extend the picture of breaking a
basic law of restraint to civil process, where we find every police
officer’s nemesis, the evidence that proves the criminal’s guilt, yet
is found to be obtained unlawfully. What happens here is that a known
criminal goes free, as must occur to uphold the prevailing law, and yet
society as a whole, while agreeing with the finding, is stressed by the
injustice.
We can make a parallel case happening in the
computing environment. Inefficiencies and inappropriate knowledge
transfers occur all the time because of tight coupling when it’s not
necessary. It is to reduce these stresses and increase options and
extensibility that object oriented programming arises in the first
place, and the theme of relaxing these pressures is flowering now into
an entire architectural paradigm of loose coupling.
But to
achieve loose coupling doesn’t mean that programmers and designers can
relax, that’s not what it means. The business of making computing
easier for the users is a lot like creating wiser laws, and then
following them. Creating them is hard in the first place: following
them takes a culture of programmers like Yi Wen and Dan Manges, in a
sort of neighborhood watch ever alert for wrong activity. Loose
coupling takes eternal vigilance, and the occasional flight of fancy in
its description.
