[newbie] Looking for a good introduction to object oriented programming with Python
steve+comp.lang.python at pearwood.info
Tue Aug 7 07:19:00 CEST 2012
On Mon, 06 Aug 2012 09:55:24 +0100, lipska the kat wrote:
> On 06/08/12 01:22, Steven D'Aprano wrote:
>> On Sun, 05 Aug 2012 20:46:23 +0100, lipska the kat wrote:
>>> Object Oriented programming is a mindset, a way of looking at that
>>> particular part of our world that you are trying to encapsulate in
>>> computer language. The language you use is (should be) irrelevant.
>> That depends on how you define OOP, and in particular, which aspects of
>> OOP your language supports.
> The clue is in the name 'Object Oriented' ... anything else is (or
> should be) implementation detail.
So your argument is that any programming which is "oriented" (meaning
what?) towards "objects" (which are...?) is OOP, and everything else is
Well now I'm enlightened. That certainly clears that up for me.
> [large snip]
>> In particularly, terminology varies -- I personally despise with the
>> heat of a thousand suns the terms "instance variable" and "class
>> variable" for attributes or members.
> This is an implementation detail and describes the difference between
> certain types of attributes.
Not everything is an "implementation detail". The difference between a so-
called "class variable" (what Python calls a class attribute) and a
"instance variable" (instance attribute) is not an implementation detail,
it is a difference in semantics and function.
As you go on to explain:
> A class variable is static and can be
> accessed without instantiation an instance variable is accessed via an
which are semantic differences, differences in meaning and function.
>> Since a "string variable" is a variable holding a string, and a "float
>> variable" is a variable holding a float, an instance variable should be
>> a variable holding an instance, and a class variable should be a
>> variable holding a class.
> Class variable and instance variable are higher level abstractions.
Of what? Of variables? "Class variables are an abstraction of
variables"... even if true, that's a crappy way to speak. Why should you
use the same word for higher level abstractions that is already used for
lower level abstractions?
I understand that in Java, classes are not first-class (no pun intended)
objects. You can't say:
x = MyClass
and hence talk about x being a variable that holds a class, hence "class
variable". But that's no excuse to overload the term "variable" for
something where there are at least three good names:
none of which clash with the normal use of the word "variable".
(Smalltalk gets a pass here -- it was very early days in OOP, and the
terminology wasn't available. But by the time that Java came along, there
was no longer any good justification for overloading a perfectly good
word like variable to mean something different.)
Simply put, the choice of terminology is crap -- attributes of a class/
instance have subtle but real semantic differences from local/global
variables. Attributes belong to an entity (an instance, or a class);
variables do not.
If they were just implementation differences ("local variables live on
the stack, attributes live in the instance struct") it wouldn't matter.
But the semantics are different, and the "instance variable" terminology
But what *really* gets me is not the existence of poor terminology. I
couldn't care less what terminology Java programmers use among
themselves. What gets me is that the ubiquity of them means that
substandard terminology spreads into other languages, like dryrot.
>>> The ONLY concept that you should never try to encapsulate is/are human
>>> beings or their aliases.
>> Is this some sort of mystical "humans aren't objects, they're
>> SPECIAL!!!" rubbish? Because it sure sounds like it.
>> Can you give some non-religious reasons why you should not implement
>> human beings or aliases as objects?
> You have answered your own question....
I'm afraid I have no idea what you mean here. Do you mean that you
*don't* have any non-religious reasons for avoiding Person and User
How do you feel about Person and User structs, records or fields?
> I would be glad to debate my
> assertion at length with you however the 'moderators' are listening.
There are no moderators on this list. People are free to try using peer
pressure to discourage off-topic discussion, but they can't enforce it.
>>> I've already managed to write meaningful code but I haven't invented a
>>> single class yet.
>> And why do you think this is a problem?
> A problem? I wasn't aware that I'd stated it was a problem it just
You said "BUT [emphasis added] I haven't invented a single class yet",
which implies that this is a bad thing in contrast to the good thing that
you became productive in Python very quickly.
> underlines my belief that Python, however useful it is, is not the ideal
> language to learn about Object Oriented software development.
I guess that depends on whether you learn best from a gentle learning
curve with incremental gains in knowledge, or by immersing yourself in an
entirely unfamiliar environment with a steep learning curve to "sink or
> > and a Facade is just an interface layer.
> Well as you seem to be so concerned with terminology I'd have to
> disagree with you here. An interface (in computing) has any number of
> meanings, hardware interfaces, software interfaces the HCI etc etc.
All of which have in common that they are a layer (hardware, software, or
something else) between two entities (objects, hardware components,
people, substances, environments, etc.).
Which is exactly what a facade is.
> some languages an interface is a non functional unit of compilation that
> describes the methods an implementing class must provide.
And even in those languages (Pascal, for example) an interface is also an
interface, not just an instruction to the compiler stating what interface
elements are required.
> A facade on
> the other hand aggregates a number of fine grained operations that often
> implement the business logic of an application into coarser grained
> methods that can be called further up the implementation stack.
Which makes it an interface to those fine-grained operations.
Just because the word "interface" is a reserved word in Pascal with a
specific technical meaning and "facade" is not does not mean that the
general term "interface" does not also apply to facades.
> importantly, what goes on behind a facade can be completely changed
> without affecting anything that uses the facade thereby enhancing
> maintainability. (I'm trying really hard not to use buzzwords here).
Which is exactly the point of an interface. You can change the
implementation behind the interface (the fine-grained operations) without
needing to change the higher-level facade operations.
I'm not arguing against the usefulness of "facades". I am questioning why
they need to be singled out as a named "design pattern" instead of just
one mere example of a more general, less specific technique of building
an interface to another system.
You have a complicated, fine-grained system which is difficult to use?
Write an interface, then talk to the interface.
You have a simple, but buggy, system, and need a layer of code to work
around the bugs? Write an interface, then talk to the interface.
You have a system which changes rapidly? Write an interface, and talk to
There's no need to teach multiple different design patterns in isolation:
"facade", "adaptor", "bridge", "connector", "proxy"... They're all the
same pattern. If you learn the general idea of an interface, the rest are
obvious. Or at least more clear and less jargon.
More information about the Python-list