OO approach to decision sequence?

[Chinook]

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