[Tutor] object design question

Kent Tenney ktenney at gmail.com
Wed May 16 13:55:16 CEST 2007


Alan Gauld <alan.gauld <at> btinternet.com> writes:

> 
> "Kent Johnson" <kent37 <at> tds.net> wrote
> >> Howdy,
> >>
> >> I would be interested in some discussion of
> >> which of the following approaches is preferred and why.
> >>
> >> class RstManager:
> >>     def __init__(self, text):
> >>         self.parsed = parseRst(text)
> >>     def parseRst(self, text):
> >>         parsed = <do stuff to text>
> >>         return parsed
> >
> > If you have no further need of text, I prefer the second. If you 
> > need to
> > keep text around then use the first one or possibly
> 
> I agree with Kent J. It depends a lot on what else your class is 
> doing.

OK, so there's not "one right way" to handle this.
Assigning via the method return is more explicit, I thought
class design guidelines might frown on passing values back and forth.


> If it needs text or if it will parse reguilarly.
> 
> However I'm also always suspicious of a class called xxxManager.

OK, very generous response. I'll expand on what I'm doing.

The class I'm working on does conversion between ReStructuredText
and the Leo (http://leo.sf.net)file format. It also 
wraps rst->html rst->xml etc.

The class is currently name ``Sections``.
The interface consists primarily of properties 
for the different types.

s = Sections()
s.rst = 'document.txt'
leo_version = s.leo
html_version = s.html

s.leo = 'document.leo'
rst_version = s.rst
xml_html = s.html

The implementation involves lots of choices like the
original post, do the variables get returned by 
conversion methods, or do the methods set the 
class variables?

I'm not sure if 'Manager' is the correct term here.

Thanks,
Kent

> 
> Classes are by definition there to manage some data by
> providing some behaviour. Usually the Manager bit can
> be left off the name. Then the class is just Rst.
> 
> I don't know what an Rst is, but my guess is that you will
> want one of them as an object rather than some kind of
> manager object. To use a more mundane example:
> 
> class FileManager:
>     def open(self, name): ....
>     def close(self):....
> 
> fm = FileManager('foo.txt')
> 
> Do I really want a file manager object or do I want a file?
> Which is the object? Often when we thinkmof objects as
> managers we are really thinking in terms of some data
> that we want to apply functions to. Really we should be
> thinking of the class as representing the objects themselves.
> 
> If you do have a real manager object it is usual for it to contain
> one or more of the things it manages, thius you'd expect
> the definition to look something like:
> 
> class FooManager:
>    def __init__(self, aFoo):
>       self.Foos.append(aFoo)
> 
>    def sort(self):....
>    def find(self,aFooRef):....
> 
> ie The init takes a Foo as an argument and manages a
> collection of Foos.
> 
> But I don't know your domain and you may well really mean
> an RstManager. But its worth considering, it may well make
> your code more intuitive to read.
> 
> If you want to read much more on this theme try and find
> a copy of the book OOP by Coad and Nicola. They discuss
> the problems that can arise in an OOP program with Manager
> objects.
> 
> HTH,
> 






More information about the Tutor mailing list