Hi Mike:

I agree with your discussion of the analogy; it is not 
perfect but still useful I think.

I think that your intuition about finding strategies is similar to mine.
I find the strategies during analysis and design based on
a high-level view of the system to be built. I embed then the strategies
into the leaves of a tree and add gradually more detail until
I have a class graph at the root of the tree which can represent
all the objects I need.

I look forward to your discussion of those issues in the itinerary chapter.

-- Karl


>From werner@ccs.neu.edu Fri Feb 20 10:08:52 1998
>
>> In summary:
>> 
>> Relational DBMS		Programming
>> 
>> Normalization		Law of Demeter
>> follow
>> 	many narrow		many small methods
>> 	relations
>> 
>> 	requires more joins     requires more navigation
>> not follow
>>         large relations		large methods
>> 	maintenance problems    maintenance problems
>> 
>> 
>> This may be a superficial analogy, but it sounds a lot like normalization
>> of relational database schemas: if you normalize, you get lots of "narrow"
>> relations which are easy to maintain, but require joins to answer queries;
>> if you don't, you get "wide" relations that are hard to update.
>> 
>> -alberto.
>> 
>> 
>Interesting analogy between LoD and database normalization but I'd like to 
>pick at it.  LoD strikes me as being more about how to navigate through
>classes that already exist, rather than about deciding on the class
>structure in the first place.  The LoD question is whether to accomplish the
>navigation by using expressions with multiple dereferencings or whether
>to distribute accessing methods to the so-called stepping stone classes
>and have simpler, less brittle expressions.  Adaptive programming
>automates the distribution of the accessing methods.
>
>My point is that the class structure is decided on during analysis, and 
>then during design when following a methodology such as OMT or UML.
>"Normalization" decisions are made then.  I see LoD as being more of
>a programming guideline belonging in the implementation phase.
>
>The bigger question is how to hide some of the details of the class
>structure to ease comprehension and maintenance.  Strategies offer
>a way to do this.  For me the question is not the mechanics
>of strategies, but how to decide back in analysis and design, what
>strategies are needed.  I have my own take on this, which is to 
>look at a shared system from the viewpoints of different classes of
>users and to identify and design strategies corresponding to these
>viewpoints.  I plan to bring this out in the chapter of my dissertation 
>dealing with "itineraries".
>
>-Mike Werner
>