Skip to Content.
Sympa Menu

pcplantdb - [pcplantdb] OO design info

pcplantdb@lists.ibiblio.org

Subject: pcplantdb

List archive

Chronological Thread  
  • From: Chad Knepp <pyg@galatea.org>
  • To: pcplantdb@lists.ibiblio.org
  • Subject: [pcplantdb] OO design info
  • Date: Sat, 7 Aug 2004 14:25:05 -0500

John Schinnerer writes:
> Aloha,
>
> Chad, thanks for posting the zope site article on OO design. Hadn't
> seen that one myself and it was well and clearly written - hopefully
> clarifies some of my early ramblings about why IMO OO is the way to go
> for what we're trying to do - model complex objects and their interactions!
>
> Rich brought up the question of what objects we need...
> My very brief response is basically what the article says about OO
> design...one starts with the most basic elements - ideally common to
> most everything we'd eventually create - and creates a base class
> (simplest objects we'll have). There may be a couple of these, not
> necessarily just one.

<techie rant> Yes, I was planning on a base class that pretty much
every object in ZODB would inherit from. Some other structural ideas
I've had is that I would like to put most/all the objects in one
IOBTree ({'Integer': 'Object'} Balanced Tree). Every Object will have
an Integer key/id. There could be Object keys, but I can't see the
need and I suspect Integer keys will perform better. One tricky thing
though is creating unique integers for all the objects. My solution
so far is to use a persistent generator function
<http://python.org/doc/current/tut/node11.html#SECTION00111000000000000000000>.
ack! uses a kind of primitive counter that I doubt is thread
safe... possible to have data loss at high levels of object creation
in multiple concurrent connections. Anway, the base class __init__
would call this generator function to get it's object id, assuring
safe unique ids. </techie rant>

There will also be Zope application objects that will somewhat
seperate from the stuff in ZODB.

> So what attributes (data) and methods (code) are most fundamental to
> what we're doing?
> Should we have a wiki page for tracking this thread...?
> Chad, have you already got a working idea of where to start here?
> If so pass it around, let's see what the rest of us make of it.

Plant objects are pretty obvious, at least the attributes. I will
submit an attribute proposal based on our current dataset for comments
in the very near future. After it stabilizes it would probably be a
good wiki page. I would like to be on the side of having attributes we
don't ever use than having to add them later although I suspect we
will certainly need to tweak something later on. Anyway it already
seems easier than trying to change the schema in an RDBMS.

> Anyhow...from there on, the base classes (the "blueprints" for our
> simplest essential and necessary objects, which contain attributes and
> methods we think will be common to all our objects) are used to build
> more complex classes, which can then themselves be used to build yet
> more complex classes, and so on...and so on...and so on... :-)

class HGObject ():
"Base class"

class Comment (HGObject):
"Inherits HGObject"

class Article (Comment):
"Like a comment but with more features"
"Inherits Comment which inherits HGObject and so on..."

An interesting thing in my experience of OO programing is that I don't
usually write base classes in their entirety right away. Actual
development of the classes is almost parallel and I often realize that
something in a subclass (the more complex class) could actually be
generalized and should be in the superclass (the base class).

--
Chad Knepp
python -c 'import base64;print base64.decodestring("cHlnQGdhbGF0ZWEub3Jn")'




Archive powered by MHonArc 2.6.24.

Top of Page