OO approach to decision sequence?

0 views
Skip to first unread message

Chinook

unread,
Jun 18, 2005, 2:17:32 AM6/18/05
to pytho...@python.org
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

Jordan Rastrick

unread,
Jun 18, 2005, 3:32:43 AM6/18/05
to
I've coded some simple recursive tree data structures using OO before
(unfortunately not in Python though). It's not nessecarily an
ill-suited approach to the task, although it depends on the specific
details of what you're doing. What's the the piece of code from which
your if...elif fragment is taken actually supposed to do?

Without knowing more about your problem, I think the most obvious OO
approach would be to write a seperate (simple) class for each of
node_type_1, node_type_2, etc. Make sure each one provides the same
interface, i.e. defines the same set of methods. Then put the different
decision branches as implementations of a certain method in each class.

class Node_Type_1(object):
def recurse(self):
# do stuff here

class Node_Type_2(object):
def recurse(self):
# do other stuff here

only make sure you use more informative names than "Node_Type_1" and
"recurse" :)

Your if elif code then collapses to:

node.recurse()

where the node variables refers to an instance of any one of your
Node_Type classes.

OO isn't magic. You still in the end have to write the code that
implements the decision choices. In this example, its likely the OO
code is actually more verbose, since you have all the class and method
definitions to write as well.

But there are advantages. Adding new cases (new node_types) is simpler
and less error prone - you just write a new node_type class. The code
for the new class, unlike a new elif brach, is kept cleanly and safely
seperate from your existing, correctly working code. If you forget to
provide the new class with the recurse method, you get a runtime error.
But if you forget to add the case to your if..elif statement, you just
end up silently going with your sentinel "else" branch, which may not
be what you really want to do with that node_type. (in fact I'd usually
raise an exception on reaching the else branch in any such extended
if..elif structure, because it's almost always the result of an error
in your program logic)

Essentially, although you may end up writing more code, its also better
organised, since as you wish it avoids your 'conventional lengthy if
struture'.

Its a partciularily useful approach if you have several different
functions that need to branch on node-type in this fashion (e.g. pretty
print the tree, post-order traverse it, run a search over it, etc). For
each such function, you just provide a method on every node_type class.
Again, if you forget to provide the code for a certain node_type, the
error is very easy to detect.

If your problem is simple, the OO approach may be overkill - your
current if..elif code may be the most straightfoward solution. But if
the problem is complicated, or has the potential to grow more
complicated, the advantages of the OO approach may be a worthwhile
trade off. Fortuantely Python is a multi-paradigm language, so the
choice to use or not use OO according to what best suits the design and
the problem is left up to you, the programmer, and is not thrust upon
you by the language.

And you certainly don't want metaclasses or anything else that complex
and deep for something like this.

John Machin

unread,
Jun 18, 2005, 3:52:57 AM6/18/05
to Jordan Rastrick
Jordan Rastrick wrote:
> I've coded some simple recursive tree data structures using OO before
> (unfortunately not in Python though). It's not nessecarily an
> ill-suited approach to the task, although it depends on the specific
> details of what you're doing. What's the the piece of code from which
> your if...elif fragment is taken actually supposed to do?
>
> Without knowing more about your problem, I think the most obvious OO
> approach would be to write a seperate (simple) class for each of
> node_type_1, node_type_2, etc. Make sure each one provides the same
> interface, i.e. defines the same set of methods. Then put the different
> decision branches as implementations of a certain method in each class.
>
> class Node_Type_1(object):
> def recurse(self):
> # do stuff here
>

etc etc

and perhaps if you found by the time you got to Node_Type_2 that its
opensesame() method was identical to the opensesame() method for
Node_Type_1, you might decide that having separate simple classes could
be improved on by having a Node class, which you would subclass for each
Node_Type_n ...

Brian van den Broek

unread,
Jun 18, 2005, 3:52:28 AM6/18/05
to chino...@tds.net, pytho...@python.org
Chinook said unto the world upon 18/06/2005 02:17:


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


Chinook

unread,
Jun 18, 2005, 4:39:54 AM6/18/05
to pytho...@python.org
On Sat, 18 Jun 2005 03:52:28 -0400, Brian van den Broek wrote
(in article <42B3D2BC...@po-box.mcgill.ca>):

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


George Sakkis

unread,
Jun 18, 2005, 9:10:25 AM6/18/05
to
"Chinook" wrote:

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

What you are looking for is what is called the 'factory method pattern'
(http://en.wikipedia.org/wiki/Factory_method_pattern) and it's one of
the cases where OOP doesn't eliminate the if/elif/elif (or switch in
C++/Java). That's ok though because, as you noticed, at some point you
have to take a decision. What's important is the "once and only once"
principle, that is all the decision logic is encapsulated in a single
method (or in python in a single function) instead of being replicated
every time you want to use an existing Node.

Regards,
George

Chinook

unread,
Jun 18, 2005, 2:53:48 PM6/18/05
to pytho...@python.org
On Sat, 18 Jun 2005 09:10:25 -0400, George Sakkis wrote
(in article <1119100225.4...@f14g2000cwb.googlegroups.com>):

George,

Yes, that answers my question of how the issue is approached in OOP - thank
you. I'll do some more googling to find examples in Python and then try
refactoring my little utility. The effect on my little utility will be a
verbose abstraction of a specific efficient top-down approach, but the
intended goal is to learn how to better facilitate extensibility.

Thanks to all that took the time to wade through my post and especially to
those that offered their thoughts,

Lee C


Thomas Lotze

unread,
Jun 20, 2005, 7:05:14 AM6/20/05
to
Jordan Rastrick wrote:

> Without knowing more about your problem, I think the most obvious OO
> approach would be to write a seperate (simple) class for each of
> node_type_1, node_type_2, etc.

While I agree that this is the cleanest and usually simplest approach,
it does have its drawbacks. I'm currently working on a project where I'd
very much like to avoid writing a whole set of classes just for the
purpose of avoiding a decision chain.

For a PDF library, I need basic data types that are used in a PDF
document. Such are integers, floats, strings, lists, dictionaries and a
few. At some point they have to be written to a file, and at first I was
tempted to create types like pdfint, pdffloat, pdfstr etc. which
implement the respective file encoding either in a write method or
directly in __str__.

However, the whole point of the library is to allow working with the
document's data. Beside manipulating existing (as in read from a PDF
file) mutable objects this includes creating new objects of type pdffoo.
And I realized it is very bothersome to have to say x = pdfint(5)
instead of x = 5 everytime I deal with integers that would end up in the
document. Similar for, e.g., adding to PDF integers: x = pdfint(y+z)
instead of just x = y+z.

The latter can be cured by touching all methods returning any pdffoo
instances. No sane person would do this, however, and it would not
eliminate any pdffoo(x) type conversions in the app code anyway.

So I decided that in this case it is best to go without special types
and use those provided by Python, and live with an ugly decision chain
or two at defined places in the library.

--
Thomas

Magnus Lycka

unread,
Jun 21, 2005, 7:41:45 AM6/21/05
to
Chinook wrote:
> 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.

There are several aspects and approaches here, depending on
the data. If you receive a stream of text, you might want to
build a parser to handle that. For instance you might want
to use something like PyParsing. That's not really an OO
approach, but once you have your objects, it's time for OO! :)

Note, that while the basic approach of the factory patterns is
applicable to Python, most texts describe how to use it with
C++ or Java, and do a large degree, they are complicated by
shortcomings in those languages (such as static typing and
reliance on inheritence for polymorphism) that are non-issues
in Python. IOW, keep it simple.

Bengt Richter

unread,
Jun 26, 2005, 12:54:42 AM6/26/05
to
On Sat, 18 Jun 2005 03:52:28 -0400, Brian van den Broek <bva...@po-box.mcgill.ca> wrote:
[...]

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

The OP might want to consider factoring report into a base class, e.g.,

>>> class Base(object):
... def art_name(self):
... cname = type(self).__name__
... art = 'an'[:1+(cname.upper() in 'A E F H I L M N O R S X' or
... len(cname)>1 and cname.upper()[0] in 'AEIOU')]
... return art, cname
...
>>> class A(Base): pass
...
>>> class B(Base): pass
...
>>> class F(Base): pass
...
>>> class Foo(Base): pass
...
>>> class U(Base): pass
...
>>> class Uhuh(Base): pass
...
>>> items = A(), B(), F(), Foo(), U(), Uhuh()
>>> for item in items: print 'Found %s %s' % item.art_name()


...
Found an A
Found a B

Found an F
Found a Foo
Found a U
Found an Uhuh

Returning info rather than printing to stdout allows you
to access and use it differently, e.g.,

>>> items[3].art_name()
('a', 'Foo')
>>> items[3].art_name()[1]
'Foo'

(Don't know if the a/an logic is really general ;-)

Regards,
Bengt Richter

Chinook

unread,
Jun 26, 2005, 3:22:13 AM6/26/05
to pytho...@python.org
On Sun, 26 Jun 2005 00:54:42 -0400, Bengt Richter wrote
(in article <42be2920....@news.oz.net>):

Thanks Bengt,

I'm just in the middle of refactoring my perfectly good top down utility to
an OO approach. It's going to be a much more abstract and verbose animal,
but that's OK because it's a learning exercise. To make use of the
abstraction I'm providing for output options of either .csv or .html table,
and I was approaching such with a separate output base class. I don't have
the nuances of the language down yet, but you might say I'm taking an AO
approach to OO refactoring??? :~) Streatching it a bit probably in calling
processing and reporting the two main aspects of an AO approach, but it's fun
and keeps my head busy. I've got a trial mockup of my decision sequence
factory pattern working, so at least I'm making progress towards
incomprehensible abstraction :<)) To avoid duplication I'm using code
objects with my factory pattern to create applicable class methods for an
instance. Yea, I'm overdoing it, but as I said it's a learning exercise.

I'll study what you supplied in the morning to see if I understand. That and
continue putting up firewood for next winter - tiring work in the 90 degree
weather we're having in northern NE - especially at my age.

Thanks again,
Lee C


Paul McGuire

unread,
Jun 26, 2005, 5:14:50 PM6/26/05
to
Lee C -

Here is a technique for avoiding the if-elseif-elseif...-else method
for building objects. It is a modified form of ChainOfResponsibility
pattern, in which you have a collection of factory methods that all
have a common signature, or a collection of Factory classes that all
implement a "makeObject" method. These common methods probably take a
string, and return a generic object. Fortunately, such type
flexibility is *very* easy in Python. :)

Example:
I want to convert individual strings to native data types. I want to
detect integers, reals, complex numbers, and booleans (indicated by
'True' or 'False'). This is kind of similar to a parsing problem, but
it could also be used for deserializing or unpickling data of an
unknown original type.

Note the special treatment I have to go through with boolean values - I
needed to write a special makeBool routine, since Python will take any
non-empty string to be True, when what I want is 'True' to yield true
and 'False' to yield false.

Hope this gives you some alternative ideas to your cascading if's.

-- Paul


def makeBool(s):
if s in ('True','False'):
return s == 'True'
raise ValueError

converters = [ int, float, complex, makeBool, str ]

def makeObject(stringVar):
for conv in converters:
try:
val = conv(stringVar)
except Exception:
continue
else:
break;
return val

def test(s):
val = makeObject(s)
print s, val, type(val)

test('1')
test('1.0')
test('1+2j')
test('1+0j')
test('True')
test('False')
test('A')

prints:
1 1 <type 'int'>
1.0 1.0 <type 'float'>
1+2j (1+2j) <type 'complex'>
1+0j (1+0j) <type 'complex'>
True True <type 'bool'>
False False <type 'bool'>
A A <type 'str'>

George Sakkis

unread,
Jun 26, 2005, 5:58:11 PM6/26/05
to
"Paul McGuire" <pt...@austin.rr.com> wrote:

Nice technique. Something that needs to be pointed out is that the
order of the converters *is* important; int takes precedence over
float, which take precedence over complex and bool takes precedence
over string. More succinctly:
{ int -> float -> complex }
{ bool -> str }
In general the converters will form a strict partially ordered set, so
the list of converters should be a topological sort of the respective
DAG.

George

Chinook

unread,
Jun 26, 2005, 9:03:45 PM6/26/05
to pytho...@python.org
On Sun, 26 Jun 2005 17:58:11 -0400, George Sakkis wrote
(in article <1119823091....@g44g2000cwa.googlegroups.com>):

Ah yes, there is more than one way to skin a cat :~) and your samples are
helping me get a better grasp of both Python and OOP in such. I find both
Bengt's and Paul's variation on a theme understandable (I must be making
progress :~) and interesting. I must admit that I did have to look twice at
Bengt's clever little slice on 'an' though.

I had already worked my way through <a
href="http://fraca7.free.fr/blog/index.php?2005/02/28/2-design-patterns-part-
i---chain-of-responsibility">this</a> though, so they were that much more
understandable.

Actually, I'm using a superclass as a factory, similar to Steve B's example
(as modified by someone I can't find the name of). The difference is that my
criteria does not map easily to class names so I have the verbose decision
sequence in my superclass. Of course, if I want to get really fancy, I
could use the COR pattern within such.

I'm making more hay out of this one little pasture than I expected (i.e.
increasing my understanding) thanks to all of you. I'm going to have to
start writing down names (rather than rely on this ol head) so I can properly
thank everyone - like those clarifying other examples.

At some point I'll put up the original top-down and OO refactored versions of
my little utility in the hope that I will learn even more from criticism of
my efforts. The "new deal" top-down structured programming encountered in my
continuing post grad work at BU in the 1960s was easier to get a solid handle
on ;')

Much appreciated,

Lee C

"Wonder rather than doubt is the root of knowledge." --Abraham Joshua Heschel


Paul McGuire

unread,
Jun 26, 2005, 11:34:03 PM6/26/05
to
Ok, I'm glad you guys liked that design pattern. Here are a few
additional footnotes:

1. As George mentions, the order of the converters is *very* important,
especially in this particular case. One might question whether '1+0j'
would convert to a complex or an int - my first thought was to make it
an int, but that made the example more complicated, and I didn't really
need to be fussy to make the example.

2. If this were a design for a deserializer, it would be a bit poor, if
only because of this order-sensitivity. Also, there is no way to
reconstruct a string containing a value that maps to one of the other
types, such as 'True' or '1'. A better deserialize/serialize design
would support quoted strings so that a string of '"1"' would not be
misinterpreted as an int. But again, I didn't want to take on
deconstructing quoted strings, escaped characters, etc. But in
general, when designing a deserializer/serializer, it's better to make
the output more unambiguous.

3. I once had an O-O expert tell me that this was not really a
Chain-of-Responsibility pattern. His take was that, in COR, each link
succeeds, or calls the next link in the chain. In my design, each link
is just one of a collection, and succeeds or raises an exception; the
iteration is done from the calling routine. I really haven't found a
name for this pattern, so I just call it "modified COR".

-- Paul

Reply all
Reply to author
Forward
0 new messages