Does Python really follow its philosophy of "Readability counts"?
Russ.Paielli at gmail.com
Wed Jan 14 02:50:05 CET 2009
On Jan 13, 5:29 pm, alex23 <wuwe... at gmail.com> wrote:
> On Jan 14, 10:45 am, "Russ P." <Russ.Paie... at gmail.com> wrote:
> > The Wikipedia entry for "object-oriented programming" also lists
> > encapsulation as a "fundamental concept."
> The Wikipedia entry for "encapsulation" defines it as "the grouping
> together of data and functionality".
> That sounds like Python classes & modules to me.
Here's the definition on the Wikipedia page for object oriented
programming (and it does *not* sound like Python classes):
Encapsulation conceals the functional details of a class from objects
that send messages to it. ... Encapsulation is achieved by specifying
which classes may use the members of an object. The result is that
each object exposes to any class a certain interface — those members
accessible to that class. The reason for encapsulation is to prevent
clients of an interface from depending on those parts of the
implementation that are likely to change in future, thereby allowing
those changes to be made more easily, that is, without changes to
clients. For example, an interface can ensure that puppies can only be
added to an object of the class Dog by code in that class. Members are
often specified as public, protected or private, determining whether
they are available to all classes, sub-classes or only the defining
class. Some languages go further: Java uses the default access
modifier to restrict access also to classes in the same package, C#
and VB.NET reserve some members to classes in the same assembly using
keywords internal (C#) or Friend (VB.NET), and Eiffel and C++ allow
one to specify which classes may access any member.
More information about the Python-list