Polymorphism the Python way

Alan Gauld alan.gauld at btinternet.com
Tue Sep 2 23:50:50 CEST 2003


On Tue, 02 Sep 2003 16:34:37 +0200, Bertel Lund Hansen
<nospamius at lundhansen.dk> wrote:
> "Encapsulation" is the word that describes the effort(s) to make
> it impossible for the user of a module to access the attributes
> (and hidden methods) directly and only allow him to do it through
> public methods with build-in check so that no disasters occur.

<RANT>
Does anyone else really hate this corruption as much as me?
It seemed to take hold when C++ appeared. Encapsulation in OO
originally meant the ability to bind data and functions together
into a single thing (that we call an object). (Some early "OO"
languages apparently provided objects without an explicit class
type construct, so they were not encapsulated objects - does
anyone remember any such beasts? They were before I joined the
OOP circus in the mid '80s.)

The ability to hide the internal data was called data hiding
(originally coined by David Parnas talking about modular
programming I believe). Encapsulation and Data Hiding were thus
two different things and Encapsulation (like  Python does) was an
essential feature of OOP along with Polymorphism (whether based
on inheritance (like C++) or inteface (like Python)). Data Hiding
was desirable but optional (several OOP languages provide
encapsulation and not Data Hiding). Similarly some OOP languages
provide polymorphism by other means than inheritance and so
inheritance also was desirable but not essential for OOP (but
that has always been a point of some debate).

I've been trying to find the exact point when encapsulation
changed its meaning to data hiding but without success. It seems
to have been around about 1990-2 somewhere...
</RANT>

Sorry, just had to get that off my chest! :-)

Alan G.


Author of the Learn to Program website
http://www.freenetpages.co.uk/hp/alan.gauld




More information about the Python-list mailing list