\section{Questions and answers}

\begin{itemize}
\item
Question: The Law violates information hiding since to follow the Law you
  have to know the "instance variable objects". You are not supposed
  to know whether a value returned by a message is an instance variable
  object or a value computed from instance variables.

Answer: The concept of "instance variable object" used in the Law 
  is a semantic one. An instance variable object is either stored
  as immediate subpart of the object or computed as a new object
  and returned by some message.
  
Remark: it is possible that some methods of a message return a
newly created object and others a new object.

\item
Question: How is the Law related to information hiding?
Answer: The Law selectively hides the protocol of a class in certain classes.
  Consider the following implication of the Law: (we need two definitions first)

  Definition: Class B is called a preferred supplier of class A if 
  B is a part class of A or
  B has a method which uses an argument of class A or
  A inherits from B or
  B creates an object of class A or
  B has a method which uses a global variable which is of class A.
  Every class is a preferred supplier of itself.

  Definition: The protocol of a class is the set of messages the class
  knows about.

  Implication of Law of Demeter: (selective information hiding)
  The protocol of a class C can only be used in methods of preferred clients
  of C.

\item
Question: How does the Law limit the effects of modifications?
Answer:

  Fact: If the protocol of class B changes 
  at most the preferred clients of class B need to be modified.

  Fact: If the immediate parts of class A change,
  at most the methods of A and its subclasses need to be modified.

  Fact: If the immediate parts of class A change, and the strong Law
  is followed, 
  at most the methods of A need to be modified.

  For a compiled system such as C++: Fact: If the Law is followed and 
  if class B is recompiled then at most the preferred
  clients of B need to be recompiled.


\item
Question: What is "associated" about?
Answer: Use the following more permissive type version of the Law:

\bv
  For all classes C, and for all methods M 
  attached to C, all
  objects to which M sends a message must belong
  to the following classes:

  The argument classes of M (including C).
  The instance variable classes of C.
  Classes of objects created by M, 
    or by messages which M sends.
  Classes of global objects.
\end{verbatim}

\item
Question: When is it justified to break the Law.
Answer: When you have a stable class organization, it makes sense to use
  the protocol of a class in other classes than preferred 
  client classes. These uses
  have to be well documented.

  Example:

\bv
  (defmethod (construction :walk) ()
    (loop for e in (send self ':child) do
      (send e ':walk)))
\end{verbatim}
  We assume that class construction does not have any instance variables,
  that the e's are not newly created objects and that there are no globals.
  Since :walk does not have any arguments, and since e can belong
  to a class different than construction, we have a violation of the Law.

  We can conform to the Law, however, by:

\bv
  (defmethod (construction :walk) ()
    (loop for e in (send self ':child) do
      (send self ':walk-auxiliary e)))

  (defmethod (construction :walk-auxiliary) ; could be inline
      (e :type universal)
    (send e ':walk))
\end{verbatim}

  Here we have effectively documented the dependency of method walk
  on class universal.

\item
Question: In C++ it is possible to explicitly call member functions of
other classes. How does this affect the Law?

\begin{example}
\bv
typedef void* ent;
class slist {
  private:
    slink* last;
  public:
    int insert(ent a); 
    int append(ent a);
    ent get();
    void clear();
    slist();
    slist(ent a);
    ~slist();
};
struct name {
  char* string;
};
struct nlist : slist {
  void insert(name* a) {slist::insert(a);}
  void append(name* a) {slist::append(a);}
  name* get()          {return (name*)slist::get();}
  nlist()              {}
  nlist(name* a) : (a) {}
// from page 207 Stroustrup
};
\end{verbatim}

Here we call member function insert of slist. This is a special feature
of C++. The Law of Demeter does not allow us 


\end{example}


\end{itemize}