Newsgroups: comp.lang.c++,comp.lang.eiffel,comp.lang.smalltalk
Path: cantaloupe.srv.cs.cmu.edu!das-news2.harvard.edu!oitnews.harvard.edu!purdue!ames!waikato!comp.vuw.ac.nz!actrix.gen.nz!dkenny
From: dkenny@atlantis.actrix.gen.nz (Des Kenny)
Subject: Re: Encapsulation: what IS it, really?
Keywords: Abstract data type, mathematics, contract
Message-ID: <DGwCGn.JGA@actrix.gen.nz>
Sender: Des Kenny
Summary: A formal contract between a client and a supplier 
Organization: Actrix - Internet Services
Date: Mon, 23 Oct 1995 10:14:47 GMT
References: <45mqke$kut@antares.lu.erisoft.se> <46041t$h56@gidora.kralizec.net.au> <465gia$js2@macondo.dmu.ac.uk>
X-Nntp-Posting-Host: atlantis.actrix.gen.nz
Lines: 92
Xref: glinda.oz.cs.cmu.edu comp.lang.c++:155905 comp.lang.eiffel:11311 comp.lang.smalltalk:29750

In article <465gia$js2@macondo.dmu.ac.uk>,
Graham Perkins  <gperkins@dmu.ac.uk> wrote:
> >s93a-ase@amanda.ies.luth.se (Anders Engwall) wrote:
> >>Here are the questions: What is encapsulation in object oriented languages? 
> >>How does it work? What defines an encapsulation? What do you see from the 
> >>'outside'? How is it implemented in, say, C++/Eiffel/SmallTalk?
> 

  I agree that encapsulation is about abstract data types. Personally
  I like the way that Bertrand Meyer defines this behaviour between 
  objects in a system as a matter of defining contracts between 
  interested parties.
  
  A client and a supplier may agree to a relationship provided they
  both meet their respective obligations and obey some general rules
  ,the Invariants, that apply to all contracts with a supplier.

  The client and the supplier may carry out the agreed contract in any 
  way that they choose. The implementation of the contract is encapsulated
  because it is independent of the contract specification.
 
  An abstract data type is a formal mathematical specification
  that has four parts: types, functions, preconditions and axioms.

  See "Object-oriented software construction", Bertrand Meyer, Prentice 
  Hall, 1988. 

  This formal specification can be defined at the Business Analysis
  phase. It may be carried out in the implementation logic in any way
  that conforms to the specification.

  Eiffel is one language that implements abstract data types in a fairly
  consistent and complete way, even though it is not a functional language
  and side effects are possible.

  In Eiffel the formal specification defines a contract between a client
  and a supplier, as well as Invariants that the supplier must abide by.

  This contract is expressed in mathematical logic at the Business Analysis 
  phase.

  However, the mathematical logic may operate as a quality manager when the 
  system is executing to ensure that the implementation logic conforms to 
  the formal specification logic.

  Software engineering research consistently finds that 50% or more of system
  errors occur at the Business Analysis phase. These errors are typically 
  the most serious and have a large down stream impact on software 
  quality of the final system.

  Defining a formal, mathematical specification to express the contracts
  between clients and suppliers can help to ensure that the specification
  is at least more likely to be logically consistent.

  The fact that the implementation logic may be checked at run time against
  the specification is another quality check point.

  Many of the errors in implementation logic will show up during development
  because the implementation logic fails to meet the formal specification.
  This is more effective than simply 'testing' the implementation logic, as
  is done in most other techniques.

  The internal state and methods used to change the state of the system 
  are logically separate from the formal specification layed down in the 
  contracts between consenting parties. However, the formal 
  specifications are themselves 'executable' at run time , when they are used
  to check that contracts and invariants are not violated.

  The specification is no longer confined to paper where it gathers dust
  and is eventually ignored as the 'source code' eventually becomes the only
  believable description of the system.

  In Eiffel the specification is physically part of the source code but 
  logically and operationally it is separate. So you have one consistent
  source document to maintain from Business Analysis to the Maintenance
  phase. 

   -------------------------------------------------------------------------
  Des Kenny

  --dkenny@swell.actrix.gen.nz











