From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID
	autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: fac41,f66d11aeda114c52
X-Google-Attributes: gidfac41,public
X-Google-Thread: 103376,f66d11aeda114c52
X-Google-Attributes: gid103376,public
From: doylep@ecf.toronto.edu (Patrick Doyle)
Subject: Re: Design By Contract
Date: 1997/08/29
Message-ID: <EFnK04.J43@ecf.toronto.edu>#1/1
X-Deja-AN: 268894126
Sender: news@ecf.toronto.edu (News Administrator)
References: <3403940F.4154@pseserv3.fw.hac.com> <EFM140.Fy9@syd.csa.com.au>
 <JSA.97Aug28172900@alexandria.organon.com>
X-Nntp-Posting-Host: skule.ecf
Organization: University of Toronto, Engineering Computing Facility
Newsgroups: comp.lang.ada,comp.lang.eiffel
Date: 1997-08-29T00:00:00+00:00
List-Id: <comp.lang.ada>


In article <JSA.97Aug28172900@alexandria.organon.com>,
Jon S Anthony <jsa@alexandria.organon.com> wrote:
>In article <EFM140.Fy9@syd.csa.com.au> nospam@thanks.com.au (Don Harrison) writes:
>
>>   - Strict enforcement of encapsulation while maximising visibility. Eiffel 
>>     offers a look-but-don't-touch view of object attributes. In Ada83,
>>     an attribute and its type has to be declared in the visible interface in 
>>     order for clients to see it's structure but then they can also update it 
>>     directly. If you declare its type as private, clients can't update it 
>>     directly but neither can they see its structure.
>
>Isn't that exactly the point?  Why should a client be able to see the
>actual structure, aka implementation????

  If you mean that Eiffel is letting the structure leak out by
providing access to data members, then that's not true.  The
Eiffel syntax for accessing a data member and calling a function
with no parameters is identical.

  So consider what we'd do in C++ to encapsulate a data member:
we'd provide an accessor function.  In Eiffel, the syntax to do
would look like this:

class GOOBER

feature {ANY}

  get_value : INTEGER is do Result := value end

feature {NONE}

  value : INTEGER

end

  Now, imagine if, for convenience, you could name the accessor
function the same name as the variable--the added word "get"
doesn't really add anything to the equation here.  What you'd
end up with is a class which would behave *exactly* like this
one:

class GOOBER

feature {ANY}

  value : INTEGER

end

  More importantly, consider the purpose of encapsulation: the
representation can be changed while the interface remains the
same.  That can happen here, too.  The above class could change
to use a DOUBLE for the representation of value:

class GOOBER

feature {ANY}

  value : INTEGER is do Result := double_value end

feature {NONE}

  double_value : DOUBLE

end

  This new class would act just like the old one as far as
clients are concerned.

  So in conclusion, no, revealing the data members in this
way does not break encapsulation.  Note, however, that this
relies on the Eiffel syntax whereby functions with no parameters
are syntactically the same as data members.

  To answer your question, the client may be able to see
the data members, but the client can't possibly *know*
that that's what's going on.  As far as any client knows,
it's dealing with an accessor function.

 -PD
-- 
--
Patrick Doyle
doylep@ecf.utoronto.ca