[Tutor] Design - Granularity of classes
alan.gauld@bt.com
alan.gauld@bt.com
Thu, 16 May 2002 17:33:48 +0100
> class UploadFile:
> def __init__(self, name, data, size, type):
> self.name = name
> self.data = data
> self.size = size
> self.type = type
> For instance, would you create a FileType class to hold the
> mime type
No but I might create a heirarchy of File classes each
supporting a different mime type. 'Type' is one of the
key indicators that you need to subclass. One goal of
OOP is to avoid special processing of the
if f.type == foo:....
elif f.type == bar:....
elif f.type == baz:...
variety.
> FileSize class to hold the type?
Maybe. It depends on what size's responsibilities are.
What do we do with a size object?
The fact that its a *File*size indicates that its an attribute
of File. So if we use a class its more likely to be a number
class rather than a size class...
> => Does it make sense? I think this strategy would add
> overhead but it might help testing for correct data type.
No it doesn't make sense unless you are going to do something
different to the normal primitive types which are objects anyway!
Class definitions should be driven by behaviour not data.
If you have a bit of data decide whether it has any intrinsic
behavior within your application. If the answer is no just
use the raw data.
At least thats how I do it :-)
Alan g.
Author of the 'Learning to Program' web site
http://www.freenetpages.co.uk/hp/alan.gauld