OOP design question

[Carl Banks]

Anthony Veale' <veale at fafnir.dyndns.org> wrote:
> 
> Hello,
> 
> I'm a newbie to OOP and Python at the same time and I'm having a bit
> of a design problem.  I can see at least one way out of my problem
> that isn't really OO,

... We'll see....

> but since I'm writing this program to learn
> some OO programming, that's a bit of a cheat.  However, it might
> turn out to be the most appropriate solution.  I just don't know.
> 
> Let me be concrete here.  I'm writing a program to edit the Opera 5
> for Linux bookmarks file.  I designed some classes for Urls and
> Folders and one for the bookmark file as a whole.  The BookmarkFile
> class contains instances of Folders and Urls.

I would say you need to be more concrete yet.  The level of detail
that you've supplied is not congruent with the level of detail that
concerns your problem of whether to subclass or augment Folder.

I'll have to make some assumptions.

I assume what you're doing is reading in an Opera bookmark file,
building a internal data stucture of Folders and Urls, manipuating the
Folders and Urls in your program, and then outputting a new file.

I assume that the bookmarks are organized into a heirarchy, much like
a filesystem.  That is, Folders can contain Urls and other Folders.

You say that BookmarkFile contains instances of Urls ans Folders--it
seems to me that BookmarkFile could or should be a subclass of Folder.
It seems that it does everything a Folder does (i.e. contains Urls and
other Folders, maybe has a name and description), but also has
additional input/output facilities.  In fact, if I we're doing this, I
don't think I would even have a separate BookmarkFile class; I'd just
use a Folder for it.


> Then when I started to design the editing program, I found that
> there are some features that I wanted to add to Folders, that are
> really only applicable to Folders when editing the bookmark file.

Well, what's confusing here is that you said you're writing a program
to edit bookmarks.  When, then, are you not editing the bookmark file?

It would be helpful to know exactly what these operations are.

I'll assume that you have "editable" and "non-editable" Folders.  What
you have to ask yourself is this: Is editabilty a temporal property or
a spatial property?  In other words, can a single folder be both
editable and non-editable depending on where and when it's used?  Or
are certain folders permanently non-editable while others are
permenantly editable?

In the former (temporal) case, you almost certianly want to just add
features to the class.  In the latter (spatial) case, you might want
to subclass Folder.  (Or, better, extract a common parent class.)


> So I'd like to subclass Folders and make sure that the BookmarkFile
> class creates Folders using the new subclass.
> 
> The questions:
>      Should I try to redesign the BookmarkFile class to use a
>      parameter to control the actual class of Folder instance?  (Can
>      you actually pass a class as a parameter?)

This question makes me think it's a spatial property.

Yes, classes are regular Python objects.  You can do something like
this:

    def add_folder (folder_class, name):
        self.folder_list.append (folder_class(name))

And call it like this:

    bookmarkfile.add_folder (EditableFolder, "Anthony's Bookmarks")

But, even if you couldn't, you could use still use if ... elseif
... else ... endif logic to choose the class.


> Or:
>      Should I try to redesign the BookmarkFile class to be easier
>      to subclass and use subclassing to control the class of Folder
>      instances?

This question make me think it's a temporal property.

It seems that editability of folders is a property not of the folders
themselves, but of the BookmarkFile.  It also seems like you're
accessing your folders through the BookmarkFile class.


> Or:
>      Should I try to isolate these "editing" functions into something
>      that gets mixed with the Folder class?

That sounds terrible.  I'd run away screaming.


> Or:
>      Is there some other approach that I simply haven't thought of?

One point of confusion I've often experienced in containment
relationships (one object contains another) is whether an opertation
that involves both container and containee (or, if you will, parent
and child) should be part of the parent class or the child class?

Based on my experience, these functions should always be part of the
parent.

So, if these "editing" functions of which you speak are of that sort
(like, "move_to_another_folder"), then you should think about whether
these functions properly belong to BookmarkFile.


> The cheat would be to just add the features to the Folder class
> itself without subclassing.  It would work, but doesn't really seem to
> be the appropriate OO action to take.

... Given my best guess of exactly what your problem is, I'd say this
is in fact the best thing to do, and it's not really counter to OO....


> If I were writing this program
> in order to get something functional, I'd probably just do it.  But
> I'm trying to learn the "right way" here.

This could be your problem, too.  Sometimes the Right Way (TM) isn't
the right way.


CARL