OOP

[Jeremy Bowers]

On Thu, 28 Apr 2005 10:34:44 -0700, demon_slayer2839 wrote:

> Hey yall,
> I'm new to Python and I love it. Now I can get most of the topics
> covered with the Python tutorials I've read but the one thats just
> stumping me is Object Orientation. I can't get the grasp of it. Does
> anyone know of a good resource that could possibly put things in focus
> for me? Thanks.

The biggest problem with understanding Object Orientation is that it is
only a net gain, even when using something as nice as Python, when you
pass the trivial. 

If you're looking at provided examples of OO that fits on a screen or two
and going "And so what...?", I'd actually consider that a sign of
comprehension, not a bad thing. (No sarcasm.)

It only goes past "And so what...?" when you get into larger programs.

One example that exists in the Python library and has a lot of code
available on line is the urllib2 library. (Unfortunately, that is
something of a complicated bit of code and you're almost better off just
listening to what I'm going to say here than actually looking at the
code :-) )It uses an OO pattern called the "template" pattern, where you
bundle as much code as possible that can be used generally into a
"superclass", and inherit and specialize when you need to do something
specific.

When you want to send an HTTP request, and do something useful with the
results, you create your own request subclass. As a result of using it,
the superclass does all of it's stuff, in this case making the connection
and basic parsing of the results, so you don't have to. The superclass
then calls into the sub-class's overridden methods, based on what happened
with the request. For instance, if you are writing an RSS retriever and
the retrieval results in a 302 code, "Moved Permanently", the superclass
will call self.error_302(), and the RSS reader can then update its
personal database of RSS file locations.

OO consists structurally of the code+data combination; OO consists
*practically* of each of these little techniques, like I gave in the
previous paragraph, adding together and making things easy. None of them
are *impossible* with non-OO code, merely harder to write, but the
cumulative easing effect is quite significant.

You're probably closer to understanding the theory than you think; now you
just need to use it for a while, with an active, open mind probing for
ways to make your programming life easier. Only that will bring deeper
understanding, or maybe reading other's code if you're dedicated. You
might also look online for some of the "Design Patterns", which aren't
worth worshiping but provide a concise description of some of the other
things that OO makes easier than the alternatives.

(You may also be interested in this essay I wrote:

http://www.jerf.org/writings/bowersLaw.html

One of the problems OO faced in general, especially the late 80s and most
of the 90s, was prematurely jumping to dogma before there was adequate
community experience to formulate a *good* dogma; even today there are a
lot of "OO experts" who would take extensive exception to both this post
and that essay, even though I'm pretty sure that facts and experience are
on my side :-) . The old dogma lives on, even as many communities like
Python, Ruby, and the Testing Methodology folk are formulating better
ones. The reality of OO is that it is a rich and highly varied *family* of
techniques, which may also not be helping if you try to learn from
multiple sources; that essay tries to explore the common thread behind all
of those techniques, and explain why it is the common thread.)