[newbie] Looking for a good introduction to object oriented programming with Python

[Steven D'Aprano]

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:
>>
>>> <rant>
>>> 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 
"implementation detail".

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
> instance

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:

attribute
member
property

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 
is misleading.

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.
> 
> snip
> 
>> 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 
objects?

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 
swim".


> > 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.


> In
> 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.


> More
> 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 
the interface.

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.



-- 
Steven