View this PageEdit this PageAttachments to this PageHistory of this PageHomeRecent ChangesSearch the SwikiHelp Guide
Hotspots: Admin Pages | Turn-in Site |
Current Links: Cases Final Project Summer 2007

The General's Trench as reason for Demeter's Law - Chris Russell

To paraphrase one of Bob's sayings, when a general wants a trench dug, he doesn't want to go all the way down the chain of
command and tell the private who's stuck with the task of digging it exactly what he wants done. He wants to turn to his
second in command, tell him, "Get a trench dug here as soon as possible," and go about his merry way, without having to worry
about any of the specifics. He doesn't care who does it, he doesn't care how it gets done, and he doesn't care what tools they
use to get it done, he just wants it done.

Message sending in large object-oriented programs is much the same way: if a class way up in the hierarchy wants something
done that requires something of the objects waaaaay at the bottom of the hierarchy, the class at the top, by no means, should
try and access them directly. By doing this, you end up with Java statements that look like


or, even worse, SmallTalk statements that look like

((((topClass lowerClass) evenLowerClass) reallyReallyLowClass) peon) doSomething.

Which are difficult to read at best and nightmares to debug at worst. Instead, you want the top class to send a message one
step down the hierarchy, and then forget about it. The next class does the same, and the next, and the next until the message
reaches its final intended target and gets resolved.

Take our final project for example. When trying to design a course managements system, we came up with what we thought was a
very nice system. A Management System had Universities, a University had Semesters, a Semester had Courses, a Course had
Course Sections, and, finally, a Course Section had a Gradebook and Assignment Manager. This was all well and good until you
wanted to set a single grade in a specific gradebook, in which case you quickly ran into lines of code like the ones above.
Designing test cases for these is a nightmare, as you never know if the test is failing because the class is faulty, you're
accessing the wrong item, you're passing it the wrong message, or you're just not looking at the correct bit of data at the
correct time.

Breaking the messages up into digestible chunks makes things much easier to test, as by the time you're testing things higher
up the hierarchy, you've already had the chance to test the classes lower in the hierarchy and get them working correctly.
This means that when a test fails, you don't anywhere near as many possible causes for the failure, and can more quickly home
in on the problem.

This is an example of one aspect of a rule taught later on this class: the Law of Demeter. The Law of Demeter basically limits
what objects other objects can send messages to. One of the aspects says that objects are allowed to send messages to objects
it contains. So, a Management System can send a message to a University (since it 'has' the University it's sending a message
to), but not to a Semester (since all the Semesters are 'had' by Universities).

While it might seem a hassle, I would strongly recommend limiting how you access classes to no more than 1 or (at most) 2
levels deep. The philosophy of, 'I can, so I will,' will get you the result you want faster, but if something goes wrong,
you'll spend 3 times as much time debugging it as you would have otherwise.

Link to this Page