OO approach to decision sequence?

[Brian van den Broek]

Chinook said unto the world upon 18/06/2005 02:17:
> OO approach to decision sequence?
> ---------------------------------
> 
> In a recent thread (Cause for using objects?), Chris Smith replied with (in 
> part):
> 
> 
>>   If your table of photo data has several types of photos, and you find
>>   yourself saying
>>   
>>   if is_mugshot:
>>       #something
>>   elif is_freehand:
>>       #something
>>   else:
>>       #something
>>   
>>   then OOP will help organize your code.
> 
>     
> This struck a chord because I'm trying to refactor a top-down approach to an 
> OO approach.  The reason I am doing such is to try and get my mind wrapped 
> around OO design, not because the particular module will benefit from an OO 
> approach (it's a simple top-down recursive tree utility).  In fact it's 
> probably ill suited for OO and that is why I chose it.  
> 
> I've used an OO approach where I built up record (instance) content in a 
> variable record file, but here I'm trying to come at it from the opposite 
> direction as variable record mapping (deconstructing) would be to such.  
> 
> Anyway, a tree node can be any of seven types where:
> 
>   if node_type_1:
>     # recurse
>   elif node_type_2:
>     # terminus - do something
>   elif node_type_3:
>     # terminus - do something else
>   ...
>   else:
>     # terminus - catch all, do yet something else
>   return #to parent
> 
> So, where is the magic :~)  Seriously, how might OO help me organize this 
> type of problem (alleviate the conventional lengthy if structure)?  I've 
> looked at the cookbook, class interface techniques, factory functions and 
> metaclasses till my head is swimming. Am I missing a bolt in the machinery 
> somewhere, or simply trying to find magic that doesn't exist for a 
> straightforward decision sequence?    
> 
> Thank you,
> Lee C


Hi Lee,

I'm a hobbyist who came to grok the OO approach in the last 6 months 
or so ago. So, take the comments with that in mind.

A simple toy example with the "if type" test approach:

 >>> class A(object):
... 	pass
...
 >>> class B(object):
... 	pass
...
 >>> a = A()
 >>> b = B()
 >>> for item in (a, b):
... 	if type(item) == A:
... 		ident = "an A"
... 	if type(item) == B:
... 		ident = "a B"
...	print "Found %s" %ident
... 		
Found an A
Found a B
 >>>


Now, the same sort of behaviour where the "if type" testing has been 
replaced with code more in keeping with the OOP approach:

 >>> class C(object):
... 	def report(self):
... 		print "Found a C"
... 		
 >>> class D(object):
... 	def report(self):
... 		print "Found a D"
... 		
 >>> c = C()
 >>> d = D()
 >>> for item in (c, d):
... 	item.report()
... 	
Found a C
Found a D
 >>>


A metaphorical explanation that is a bit handwavy, but that I find useful:

In both approaches, there is a common behaviour you want the various 
types of objects to exhibit. (In a less 'toy' example the behaviour 
would be more complicated.)

In the "if type" style, you are asking each object what kind of object 
it is, and then setting an aspect of the behaviour as a function of 
the answer.

In the more OOP approach, you rely on the fact that each object knows 
what kind of object it is. So, you don't need to ask it, and adjust 
the behaviour accordingly. You just tell it to behave, and, knowing 
what kind of thing it is, it knows how to behave as befits that kind 
of thing.

Two big benefits in the context are that if you need to exhibit the 
same behaviour in multiple places, you don't have multiple "if type" 
chains, and, if you want to add a type, with its own specific 
behaviour, you just add a class, and there is no worry about hunting 
down the "if type" chains to update them.

There was a thread on the tutor list around mid-Feb. which really 
helped me come to understand the idea. Actually, from Dec. to Feb. or 
so, there are several long tutor threads where people gave me much 
useful help coming to see how to employ OOP. Might be worth a trip 
through the archive.

HTH,

Brian vdB