OOP

[Scott Robinson]

On Thu, 28 Apr 2005 17:58:47 GMT, Charles Krug
<cdkrug at worldnet.att.net> wrote:

>On 28 Apr 2005 10:34:44 -0700, demon_slayer2839 at yahoo.com
><demon_slayer2839 at yahoo.com> 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.
>> 
>
>"Learning Python" (Lutz/Ascher) has a good discussion of the basics.
>
>Unfortunately, most of the OOP writings I've read fall into two
>catagories:  Trivial examples where you say, "But why Bother??" and
>examples that you don't understand until you've some OO design under
>your belt and can understand what it's all good for.
>
>Objects are, at the end of the day, data and the accompanying methods.
>Once you've read the various tutorials take a stab at converting a
>problem you know well into objects.
>
>You'll get it wrong at first.  Most everyone does.  Don't sweat it.
>Eventually, you'll just "get" it.

[Note:  this is just the start of an explanation.  If you don't
understand OOP, just try programming that way (yes, I got it wrong to
see my usage of "Wally objects").  

This is something I thought of awhile ago, and wondered where I could
use it.  My background is a hardware guy who first learned spaghetti
coding in basic on 8-bits, received the wisdom of modular programming
when learning assembler, then much later tried his hand teaching
himself python.  Those from other backgrounds may be amused at my
naivete.]
 
I've been trying to figure out the "Dilbert" view of OOP.

My first objects were like C types:

	class Super_object:
		pass

Consider this the Wally object.

	Wally=Super_object():

Things get put on his desk:

	Wally.MeetingActionItems=[1,2,3]

And stay there.  At first, this seems great.  It gives you plenty of
desks to store data on.

After a while, you might paint yourself into a corner (such as wanting
to append to lists, but later wish to hard limit the number of
entries, thus needing to change from a list to an overloaded object).
This brings the Dilbert object.  You can put things on Dilbert's desk,
but unlike Wally, he can actually notice the objects, manage them, and
do some work on it.

Class Dilbert_object:
	__init__(self):
		ActionItems=[]
	def AddItems(self,items):
		self.ActionItems.append(items)
	
	def DoAction(self):
		return self.ActionItems.pop()	

Ok, I admit that this just looks like yet another getter and setter.
Maybe this is an Asok object and Dilbert would realize that the Boss
doesn't remember everything on his desk, so we change it to:

Class Dilbert_object:
	__init__(self):
		ActionItems=[]
	def AddItems(self,items):
		self.ActionItems.append(items)
		if len(self.ActionItems)>10:
		self.ActionItems.pop(0)	
	def DoAction(self):
		return self.ActionItems.pop()	

Since OOP dogmatists insist that inheritance is vital to OOP, we
include the Alice object.  Alice can do everything Dilbert can do, and
then some.  To include Dilbert's skills we simply include

	Class Alice_object(Dilbert_object):

To add new things to the Alice object:

	Class Alice_object(Dilbert_object):
		def FistOfDeath(self):
			import os
			os._exit(0)


The critical thing is that you can now let Dilbert manage your data.
That's one of the main reasons for inventing computers anyway, to
manage data.  So write subprograms (objects) that do your work for
you, and work as thanklessly as Dilbert, and then try to concentrate
on debugging the big picture.

Scott