Does Python really follow its philosophy of "Readability counts"?
prologic at shortcircuit.net.au
Wed Jan 14 03:04:04 CET 2009
On Wed, Jan 14, 2009 at 11:50 AM, Russ P. <Russ.Paielli at gmail.com> wrote:
> 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.
You do realize this is a model and not
strictly a requirement. Quite a few things
in Python are done merely by convention.
Don't get caught up.
More information about the Python-list