[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