Re: Re: Opinions on the Law Of Demeter
From: Universe (no email)
Date: 11/08/04
- Next message: Universe: "Re: Applying UML and Patterns"
- Previous message: Roger L. Cauvin: "Re: Opinions on the Law Of Demeter"
- In reply to: Costin Cozianu: "Re: Opinions on the Law Of Demeter"
- Next in thread: Roger L. Cauvin: "Re: Opinions on the Law Of Demeter"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Sun, 07 Nov 2004 23:25:07 -0500
Costin Cozianu <c_cozianu@hotmail.com> wrote:
>
> >>when you
> >>enlarge the interface of the Customer class, you increased the overall
> >>coupling of the system,
> >
> >
> > False. It DECREASES the coupling of client on Customer--especially
> > when no return is sent back to the client, in general in those cases,
> > as I recommend.
> >
> > Elliott
>
> Elliott, you have a serious problem counting.
>
> If you count the interface methods that define the new contract between
> the Customer class and its clients they are substantially more, because
> the Customer class just took over (unwarranted ) the responsibilities of
> Contact class.
>
> That is *increased* coupling, not decreased.
Before LoD, a contained class might have direct methods on the
containing class interface to the client.
For LoD, the containing class *need* only wrap contained class
methods.
In that case the contained class has the *same* number of interface
methods.
But even when the containing class interface is quantitatively
(numerically/by count) larger, nature does not mandate that means
there is more net effect (qualitative) coupling.
quantity<=>quality // They are dialectical opposites.
In fact genuine application of LoD DECREASES the coupling of the
client upon the contained class, even with more containing class
methods. That is *precisely* why LoD is of great value.
And of course LoD is more than about wrapping access to contained
class objects.
` It is also about limiting access to scalar class data members
like int, char, float, not just to object data members.
` LoD requires that, 1) globals and 2) *any* other unit that a
class handles, pass through method arguments for a class to
handle/access system globals, or that
` be a data member of the class
"We introduce a simple, programming language independent
rule (known in-house as the Law of
Demeter) which encodes the ideas of encapsulation
and modularity in an easy to follow form for
the object-oriented programmer. You tend to get the
following related benefits when you follow the Law of
Demeter while minimizing simultaneously code duplication,
the number of method arguments and the
number of methods per class: Easier software maintenance,
less coupling between your methods, better information
hiding, narrower interfaces, methods which
are easier to reuse, and easier correct.ness proofs using
structural induction. We discuss two important
interpretations of the Law (strong and weak) and we
prove that any object-oriented program can be transformed
to satisfy the Law.
"This Law has two primary purposes:
1. Simplifies modifications. It simplifies the updating
of a program when the class dictionary is
changed.
2. Simplifies complexity of programming. It restricts
the number of types the programmer has
to be aware of when writing a method.
The Law of Demeter, when used in coordination
with three key constraints, enforces good programming
style. These constraints require minimizing
code duplication, minimizing the number of arguments
passed to methods and minimizing the number
of methods per class."
>From the original LoD paper:
OO Object Sense of Style
by
Lieberherr, Holland, Riel
Elliott
- Next message: Universe: "Re: Applying UML and Patterns"
- Previous message: Roger L. Cauvin: "Re: Opinions on the Law Of Demeter"
- In reply to: Costin Cozianu: "Re: Opinions on the Law Of Demeter"
- Next in thread: Roger L. Cauvin: "Re: Opinions on the Law Of Demeter"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
