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