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

[Steven D'Aprano]

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.

There are lots of differences between styles and implementations of OOP 
languages, and no two languages have exactly the same feature set, but in 
general most OOP languages involve most of the following features:

- Dynamic dispatch when making method calls
- Encapsulation, or multi-methods
- Subtype polymorphism
- Object inheritance, or delegation

See here for more detail:

http://en.wikipedia.org/wiki/Object-oriented_programming#Fundamental_features_and_concepts

But beyond those fundamentals, the details of OOP can differ greatly from 
language to language. Some languages treat classes as static, some as 
dynamic. Some languages treat classes as objects themselves, others treat 
them as non-objects. Syntax varies (although the dot operator has become 
almost completely ubiquitous, there are still some exceptions).

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


> The ONLY concept that you should never try to encapsulate is/are human
> beings or their aliases. So Person, User, Human etc should not exist in
> any way shape or form in your design. There is an argument that User is
> ok but I don't subscribe to that.
>
> If you want to represent human interaction in your software design use
> Account or Session or some other non human noun. </rant>

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?

If not, let me just say that I reject your prohibition and leave it at 
that.


> Actually it should really be called Class Oriented programming as
> classes are the units of encapsulation.

Incorrect. You don't even need classes to have objects. You can have 
class-based OOP, and prototype-based OOP, as in Javascript, Actionscript, 
Io, and the language which invented the term, Self.

http://en.wikipedia.org/wiki/Prototype-based_programming


> I really don't think python is a
> good language to learn OO programming, the problem is that Python
> doesn't enforce OO so you are never going to learn what is 'OO' and what
> isn't.

I think that's exactly why Python *is* a good language to learn OOP, 
because you can be productive even while learning. You can start off by 
just adding a little bit of OOP syntax to your programs:

response = raw_input("What do you want to do? ")
response = response.lower()  # Look ma, I'm using OOP!

while still being primarily procedural. Then you can gradually learn the 
terminology ("what's an instance?"), graduate to writing your own 
classes, and then finally move on to OOP techniques which some languages 
don't even allow, like metaclasses.


> Before I get told off/flamed/shouted at I've just started learning
> Python and I think it is a great language with a fantastic standard
> library. 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?

Classes are one possible solution to problems that actually matter. What 
matters is the solution, not the mechanism of the solution. "Writing 
classes" is just a means to an end (the solution), not the end itself.


> There is a book you could try, it's a bit dry and I read it when I can't
> sleep, about 30 mins usually does it :-) It's called Design Patterns by
> Gamma, Helm, Johnson and Vlissides ISBN 0-201-63361-2.
> They do use C++ code in examples but as they say, this is just a
> convenience and shouldn't colour your view of the subject I still read
> the introduction and get something out of it after several years. You
> should be able to implement the patterns in Python although I must admit
> I haven't tried that yet

Two problems with "Design Patterns" is that many of them are excessively 
abstract, and that often they only exist to work around limitations in 
the source language (usually C++ or Java).

The first problem means that any half-decent programmer has probably been 
using "Design Patterns" for years without realising it, or knowing the 
name. I remember writing an "Object Pool" in procedural Pascal in the 
1980s to recycle resources, long before the concept was given a name. Not 
that I claim to have invented the concept -- I merely copied it from 
someone else, who described the technique without giving it a name. Not 
that he invented it either.

The emphasis on *names* is just jargon, design patterns are actually just 
problem-solving techniques. Sometimes it's useful to have jargon that 
everyone recognises, e.g. "factory function" and "singleton" are two I 
consistently remember (and I use the first *all the time* and the second 
*never*), but often Design Pattern proponents become side-tracked into 
finer and finer differences of greater and greater abstraction, at the 
expense of clarity.

In my not-so-humble opinion, the popularity of Design Patterns has a lot 
to do with the fact that they are so abstract and jargon-ridden that they 
have become a badge of membership into an elite. Shorn of their excessive 
abstractness, they're not very special. People were writing helper 
functions to assemble complex data long before the Builder pattern was 
named, and a Facade is just an interface layer.


> Learn Python by all means, the interactive mode is particularly fun,just
> try and get a good idea of what OO is all about before you start.

As far as I am concerned, any language without an interactive interpreter 
is incomplete.



-- 
Steven