Chapter 5: Bend or Break. Write “shy” code. Limits Visibility Organize code into modules ...
-
Upload
matilda-maxwell -
Category
Documents
-
view
213 -
download
1
Transcript of Chapter 5: Bend or Break. Write “shy” code. Limits Visibility Organize code into modules ...
THE PRAGMATIC PROGRAMMERChapter 5: Bend or Break
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 .ini files X11
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
This is Temporal Coupling
•Decouple temporally by allowing for concurrency
Standard
Coupling
Content
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