The Pragmatic Programmer
Download
Report
Transcript The Pragmatic Programmer
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