From Brad_Appleton-GBDA001@aieg.mot.com Sun Jun 1 23:15:44 1997 Received: from motgate.mot.com (motgate.mot.com [129.188.136.100]) by amber.ccs.neu.edu (8.8.4/8.7.3) with ESMTP id XAA02675 for ; Sun, 1 Jun 1997 23:15:41 -0400 (EDT) Received: from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate.mot.com (8.7.6/8.6.10/MOT-3.8) with ESMTP id WAA23703; Sun, 1 Jun 1997 22:15:40 -0500 (CDT) Received: from aiegil08.northbrook.aieg.mot.com (aiegil08.aieg.mot.com [155.1.11.11]) by pobox.mot.com (8.7.6/8.6.10/MOT-3.8) with ESMTP id WAA12402; Sun, 1 Jun 1997 22:15:38 -0500 (CDT) Message-Id: <199706020315.WAA12402@pobox.mot.com> Received: from sw432b1.northbrook.aieg.mot.com by aiegil08.northbrook.aieg.mot.com with ESMTP (8.8.5/HPUX-1.2) id WAA18256; Sun, 1 Jun 1997 22:15:30 -0500 (CDT) Received: by sw432b1.northbrook.aieg.mot.com (8.7.3/HPUX-1.2) id WAA13046; Sun, 1 Jun 1997 22:05:57 -0500 (CDT) Subject: Re: Law of Demeter To: David.E.Smyth@jpl.nasa.gov Date: Sun, 1 Jun 1997 22:05:57 -0500 (CDT) Cc: lieber@ccs.neu.edu Reply-To: Brad_Appleton-GBDA001@email.mot.com From: Brad_Appleton-GBDA001@email.mot.com Organization: Motorola AIEG, Northbrook IL USA X-Mailer: ELM [version 2.4 PL25] Content-Type: text Status: R Karl Liberherr writes: > Here is an interesting use of the LoD at JPL. [snip] > Today I view the LoD as a style rule about structure-shy programming. Thats my take on it as well. > It says that we should not encode too many details of the class > structure in our methods. Each method should only reveal structural > details of a limited set of classes. Yes. Expressing it a bit more "fundamentally", I regard it is being a "principal of least structural knowledge": codified behavior should make little or no assumptions about the structure of any units of encapsulation other than the ones to which they directly belong. To me, this is the very definition of "structure-shy" programming. > While the LoD is still a valuable rule for oo programming, > it reveals a flaw in oo programming: Class structure details > need to be encoded repeatedly into the method bodies. This leads > to highly redundant software which is brittle with respect > to structural changes. Allow me to attack it from perhaps a slightly different perspective. Sometimes it is useful to view an electron as a partical and other times as a wave. I think the same is true of objects. Sometimes we take the particle view (an object encapsulated by the boundaries of information hiding) and sometimes we take the "wave" view (the set ("wave") of collaborations and collaborators for a given operation). The flaw of current OOPLs is that while they provide semantic constructs to minimize dependencies when employing the "particle view", they dont provide semantic constructs to yield the same benefit for the "wave" view. They let us separate interface from implementation within the bounds of a single object or method (the particle view), but not necessarily within the relationships of all of the collaborators for a single method. The Demeter method and tools address this deficiency. They let us use protocols that specify only the preconditions, postconditions, and invariants not only for a single object method, but also for the entire family of actors that collaborate to carry out the entire "logical operation". Demeter's "succinct traversal specifications" allow us to encode _only_ the source, destination, and key intermediate members (invariants) of an information access (non-ytrivial data-flow) without having to know about all the non-critical links in the chain. So when the non-critical links come and go (or otherwise "evolve") no manual effort is required to for us to adapt to this change. The traversal invariant still holds, and only the changes to the class graph need to be made. The same codification of behavior still works simply by re-compiling the program using the Demeter tools (no procedural changes were necessary). > I agree with your point that simpler is better but traversal > strategies are simple and they simplify both initial program development > and program maintenance. Right. The new syntax may seem a bit unsettling at first, but it allows you to get the same or greater functionality by assuming "less" information. The less you have to assume, the less you need to know and depend on. The less you have to know, the simpler things should be. And, of cours, the fewer dependencies you have, the more maintainable, reusable, adaptable (and hence durable) your program will be. So if you have a method that takes a "BigMac" as an argument and needs to access the seeds on the pickles, you dont have to know about the lettuce, onions, and sesame seed bun that are all "on route" to the pickle seed (much less that there are 2 all beef patties lurking underneath all of that), all you need to know is that a path _exists_ from the BigMac to its pickle seeds. You dont have to know what that path is or exactly how to traverse it, and you dont have to encode that path in your methods. That way when the burger later changes such that the pickles are now on top of the onions instead of the other way around, you dont have to care. That looks a whole lot simpler to me (even if I do have to learn some additional traversal-spec syntax to allow me to do more by knowing less). -- Brad Appleton | http://www.enteract.com/~bradapp/ "And miles to go before I sleep." | 2800+ WWW links on CS & Sw-Eng