Chapter 5: Bend or Break
THE PRAGMATIC PROGRAMMER
DECOUPLING AND THE LAW OF DEMETER
Write “shy” code.
 Limits Visibility

 Organize

code into modules
Eliminates Unnecessary Interactions
 Limit
the number of calls to other modules
MINIMIZE COUPLING



“We do not want the object to give us a third-party object that we
have to deal with to get the required service”
When we need a service it should be preformed on our behalf.
Bad:
public void plotDate(Date aDate, Selection aSelection) {
TimeZone tz = aSelection.getRecorder().getLocation().getTimeZone();
...
}

Good:
public void plotDate(Date aDate, TimeZone aTz) {
...
}
plotDate(someDate, someSelection.getTimeZone());
COUPLING PROBLEMS
In large projects, the command linking a unit
test is longer than the unit test.
 “Simple” Changes to one module propagate
through unrelated modules.
 The developers are afraid to change code
because they aren't sure what will be
affected.

LAW OF DEMETER

Any method of an object should only call
methods belonging to:
 Itself
 Parameters
passed to it
 Object it created
 Directly held component objects (c.print();)
METAPROGRAMMING

Changes to details cause problems

So: Get the details out of the code!
DYNAMIC CONFIGURATION
Tip: Configure, don’t integrate.
 Use metadata to get configuration data OUT of
the code body.

METADATA
“Data about data”
 Any data that describes the application
 Generally, used at runtime


Examples
 Windows
 X11
.ini files
METADATA BEYOND PREFERENCES…
Program for the general case
 Keep specifics outside the main code base
 Many benefits*


Leave the details out, so easier to change
BEND OR BREAK
Application:
 Find what changes most, and attempt to code
your program in such a way that you can
change the metadata to adapt.


Don’t write dodo code
TEMPORAL COUPLING
Standard
This is
Content
Temporal
Coupling
•Decouple temporally by allowing for
concurrency
Coupling
WORKFLOW

Analyze workflow for concurrency
 You

already do it normally
Design using services
 Independent
 Concurrent
 Consistent
interfaces
ARCHITECTURE
Taking advantage of temporal decoupling
makes programs easier to write.
 Use queues to decouple tasks.
 Multiple threads can feed off the queues.
 The hungry consumer model replaces the
central scheduler with multiple independent
consumer tasks

CLEANER INTERFACES
Always design for Concurrency
 Considering time ordered can lead to cleaner
and more maintainable interfaces.
 Promotes interfaces without bugs and
surprises.

MODEL-VIEW-CONTROLLER
Modules accomplish well-defined
responsibilities
 Once those are created, how will they
communicate?
 Events signal other modules that “something
interesting happens.”

PUBLISH/SUBSCRIBE
Objects should only receive events they need
 There should only be one publisher to send
events.
 Subscribers need only to register with the
publisher to receive event notifications.

MODEL VIEW CONTROLLER
Separate views from models.
 Provides flexibility
 Allows from non traditional multiple controllers.
 Model. Abstract data model representing the
target object.
 View. It Subscribes to changes in the model and
logical events from the controller.
 Controller. A way to control the view and provide
the model with new data. It publishes events to
the model and view.

COUPLING
Listeners and event generators still have
some knowledge of each other: They must
agree on common interface definitions.
 There even more are ways of reducing
coupling.
 Web applications

Shared memory space
 Originally intended for AI systems
 Allows for a totally decoupled system

 Content
coupling
 Temporal coupling
 Single, consistent interface