[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Law and documentation
- To: lieber@corwin.ccs.northeastern.edu
- Subject: Re: Law and documentation
- From: Stanley's Tool Works <Lanning.pa@Xerox.COM>
- Date: 27 Jun 88 08:37 PDT
- Cc: commonloops.pa@Xerox.COM
- In-reply-to: karl lieberherr <lieber@corwin.ccs.northeastern.edu>'s message of Mon, 27 Jun 88 08:24:23 EDT
- Sender: Lanning.pa@Xerox.COM
...When the programmer writes a function call, he/she has to know
how the system will locate the code to execute (otherwise the wrong
code might get executed).
...The Law of Demeter promotes information restriction (in a given
method you can only call certain other methods). The concepts of
information restriction and information hiding are orthogonal to
each other and both have been proposed originally by Parnas. It is
true that the Law requires you to keep track of certain
information, but you need that information anyway to understand the
method you are writing. It is excellent documentation to your
program. -- Karl
So I can't write a piece of code for others to use without telling the user how
it is implemented? And if I write version 1 using functions, I can't use
generic-functions in version 2 without causing the poor users code to break the
(lowercase) "law"?
While the developer of a system may need to know the global structure of that
program, a user does not. The "information ... you need ... to understand the
[code] you are writing" is the structure of that code, the functionality and
interfaces to programs that you are using (but not now writing), and the fact
that those programs work. You should not need to know the internals of programs
that you use. That is one of the features of CLOS -- you don't have a different
syntax for method invocation and function call, so you need not know about
implementation details of functions you use.
And what is this about "the wrong code might get executed"? That will happen
only if I violate the input contract (or if I'm using broken code), regardless
of whether I follow the "law" or not. With this in mind, I propose "smL's Law":
>> If a functional interface requires that its input arguments
>> satisfy some property, don't pass it arguments that might violate
>> that property.
----- smL
P.S. Can we *please* stop calling this a (uppercase) "Law"? How about "The
Advice of Demeter"? Or "The Suggestion of Demeter"...