Dear David: thank you for your report about the uses of the Law of Demeter at JPL. Such reports are very valuable to us. I would like to have a discussion with you on the different facets of the LoD. Since probably several of our Web visitors are interested in your question and my response, I would like to ask you for permiision to post your question on the web. I would like to put it into: http://www.ccs.neu.edu/research/demeter/demeter-method/LawOfDemeter which contains several explanations by Brad Appleton of the LoD. Below I refer to the AP book on Adaptive Programming and Demeter described at: http://www.ccs.neu.edu/research/demeter/biblio/dem-book.html Today I view the LoD as a style rule about structure-shy programming. 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. (AP book: Chapter 8, Section 8.1. Connection to the Law of Demeter.) 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. (AP book: Chapter 1, Section 1.2. Disadvantages of oo software.) Therefore, we invented traversal specifications (now called traversal strategies) which allow for a much more structure-shy approach to programming. Traversal strategies were first used in conjunction with propagation patterns (AP book: Chapter 8, Propagation Patterns.) and now in conjunction with visitor objects. http://www.ccs.neu.edu/research/demeter/sources/DemeterJava/demo/icse/doug.html The Demeter/Java system is a new implementation of the Demeter ideas for Java. The latest source code is in the youngest subdirectory of: http://www.ccs.neu.edu/research/demeter/sources/DemeterJava/inJava/ (currently 0.4.6-JDK1.1). For general information on Demeter/Java, see: http://www.ccs.neu.edu/home/lieber/Demeter-and-Java.html I agree with your point that simpler is better but traversal strategies are simple and they simplify both initial program development and program maintenance. Please let me know whether the arguments and pointers above convince you of the value of traversal strategies to complement (NOT replace) the Law of Demeter. Now a question to your work: You write in http://mds.jpl.nasa.gov/7thIEEE.html#Demeter: ==================== Note two things: First, the Law implies that no method shall return any value (otherwise the caller cannot obey the Law). Second, the Law is really just a description of dataflow processing in the context of objects. The wonderful thing about following this Law is that the result is a set of objects which can be multi-threaded, and distributed. Temporal coupling and synchronization is eliminated, therefore avoiding three of the nastiest problems in real-time and distributed systems: critical sections, priority inversions, and deadlock. ==================== In our view it is essential that methods can return values. For example, in "this.get_x().f()" get_x() returns the data member x and calls f on it. Or it could be: "this.compute_x().f()" in case of a derived and not stored part. Your second paragraph above says very nice things about the Law which I don't understand. In which sense is synchronization eliminated? Best regards, -- Karl >From David.E.Smyth@jpl.nasa.gov Mon May 26 17:33:30 1997 >From: "David E. Smyth" >Reply-To: David.E.Smyth@jpl.nasa.gov >To: lieber@ccs.neu.edu >Subject: Law of Demeter > >I have been using LoD pervasively since about 1990, and it has taken >firm hold in many areas of the Jet Propulsion Laboratory. Major systems >which have used LoD extensively include the Telemetry Delivery System (a >real-time database begun in 1990), the Flight System Testbed, and Mars >Pathfinder flight software (both begun in 1993). We are going to use LoD >as a foundational software engineering principle for the X2000 Europa >orbiter mission. I also used it within a couple of commercial systems >for Siemens in 91-93, including a Lotus Notes like system, and a email >system. The way I have been using the LoD is covered in: > > http://mds.jpl.nasa.gov/7thIEEE.html#Demeter > >I don't quite follow your take on the Law of Demeter anymore. Maybe my >memory is faulty (it would not be the first time, I am a child of the >60's %^), but I remember discussions on the Law of Demeter in newsgroups >in 1985-1987 (probably comp.object) where, in my memory, the law was >defined as: > > "Any method must operate only on the object's existing state and > the arguments to the method: no data shall be required from any > other source during the execution of a method." > >This seems to align with your paper "Assuring Good Style for Object >Oriented Programming." where, in the third paragraph of the introduction >section, you defines the Law as: > > "Informally, the Law says that any object receiving a message in > a given method must be of a restricted set of objects. This set > of preferred objects includes the method arguments, the self > psuedo-variable, and to the immediate sub-parts of self." > >Quite possibly, the usenet discussions may have been in the 87-89 time >span. Possibly they were very closely related to your San Diego >presentation. I can't tell, since my archives of that period are on >9-track, and I am agressive at simplifying (recycling) my paper library. > >In any event, I think we were originally very closely coupled, and have >since drifted very far apart. I think you moved ;-) I'd like to talk >(email, etc) with you about it. > >I am the software lead on the X2000 program which will be developing >integrated software systems for deep space missions over the next >decade. The X2000 program embodies the new way JPL is doing business. >There are some people who are investigating CASE tools and >methodologies, and the Demeter tool set should probably be among those >we consider. > >My hesitancy is based on a strong personal belief that simpler is >better, and a superficial understanding of your recent work which seems >to be focusing on concepts that have far less power than the simple LoD. >Am I wrong? Give me pointers, so I don't waste your time. Give me >concise pointers, so I don't waste mine. Pointers to "why LoD itself is >not enough" so I can see where I have erred ;-) > >-- >- David.E.Smyth@JPL.nasa.gov http://mds.jpl.nasa.gov/David.E.Smyth >-- Snail: JPL, MS 303-310, 4800 Oak Grove Dr, Pasadena CA 91109 >--- Office: 303-310W -- Voice: (818)393-7944 -- FAX: (818)393-5013 >---- >----- Fault Tolerant Parallel Distributed Martian Web Software, etc. >------ Java + JavaOS + JavaScript + HTML + cgi-bin + perl + Darkstar >------- X2000 -- CISM -- FST -- NM DS1 -- DNP -- MPF > > "I am convinced that life is 10% what happens to me and 90% how > I react to it. And so it is with you..." > Charles Swindoll >