One purpose of the LoD (for functions) is to make a change to a class A
only affect classes "close" to A.

In analogy to the LoD (for functions), we define a LoD for strategies
(= traversal specifications). It was initially
proposed by Geoff Hulten in spring 1997.
The purpose is that a change to a class should not affect
strategies "far away".

The LOD for strategies is about splitting traversals into
subtraversals along abstraction boundaries. 

In one extreme
case, each class is an abstraction boundary: this is traditional
oo programming where each class is a black box that hides
the implementation.

In another extreme case, the entire class dictionary is 
an abstraction boundary. This allows traversals to go everywhere
but it leads to the "propagation to faraway strategies" problem.

An intermediate solution is to break the class dictionary into
subclass dictionaries which represent abstraction boundaries.
When a traversal t starting from a function f() arrives at class C
which is before an abstraction boundary class B:

C {
    x.f(); }

B {
    void f() {
      // traversal inside abstraction boundary
}

The advantage is that when classes inside the abstraction
boundary change, we need only update the traversals
starting along the boundary and not further out.