OO approach to decision sequence?

[Chinook]

On Sat, 18 Jun 2005 03:52:28 -0400, Brian van den Broek wrote
(in article <42B3D2BC.3050406 at po-box.mcgill.ca>):

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

Thanks for the reply Brian.

I understand what you are saying.  The point I'm messing up my head with 
though, is when the entity (tree node in my case or variable record content 
deconstructing in the aspect example I noted) is not an instance of a class 
already - it is obtained from an external source and only decipherable by its 
content.  

In practical terms that leaves me with some decision sequence regardless and 
I was wondering (from what Chris Smith said) how that might be done in OOP.  
The whole problem may be that I'm reading too much into what Chris said :~)  
I will dig back through the Tutor archives as you suggested.

Thanks again,
Lee C