Re: OO approach to decision sequence?

Discussion in 'Python' started by Brian van den Broek, Jun 18, 2005.

  1. 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
     
    Brian van den Broek, Jun 18, 2005
    #1
    1. Advertising

  2. On Sat, 18 Jun 2005 03:52:28 -0400, Brian van den Broek <> 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
     
    Bengt Richter, Jun 26, 2005
    #2
    1. Advertising

  3. Brian van den Broek

    Chinook Guest

    On Sun, 26 Jun 2005 00:54:42 -0400, Bengt Richter wrote
    (in article <>):

    > On Sat, 18 Jun 2005 03:52:28 -0400, Brian van den Broek
    > <> 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
    >


    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
     
    Chinook, Jun 26, 2005
    #3
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. ouadid abdelkarim
    Replies:
    0
    Views:
    2,008
    ouadid abdelkarim
    Jul 10, 2003
  2. Jim Adams

    Q&A Decision Tree in ASP.Net

    Jim Adams, Apr 27, 2004, in forum: ASP .Net
    Replies:
    1
    Views:
    737
    Jeff Bennett
    May 16, 2004
  3. Chinook

    OO approach to decision sequence?

    Chinook, Jun 18, 2005, in forum: Python
    Replies:
    7
    Views:
    313
    Paul McGuire
    Jun 27, 2005
  4. Chinook
    Replies:
    3
    Views:
    326
    Magnus Lycka
    Jun 21, 2005
  5. stef mientki
    Replies:
    13
    Views:
    646
    stef mientki
    Oct 20, 2007
Loading...

Share This Page