[Tutor] Need a solution.

Alan Gauld alan.gauld at btinternet.com
Sat Jun 13 14:55:58 CEST 2009


"spir" <denis.spir at free.fr> wrote 

>> Any time you have a class that just has an __init__ it means 
>> its not doing anything. And that's a bad sign. Classes are there 
>> to *do* things not just store data. We can use a tuple or 
>> dictionary to do that.
> 
> While this is probably true for _single_ objects in most case, 
> I guess it really makes sense to create a common structure 
> for object collections. 

I'd say that's valid for a very small number of cases which 
would normally be addressed using a record in Pascal or 
struct in C/C++. Mainly for the advantage of self documenting 
data. But a dictionary can do that too, albeit you need to specify 
the field names on construction.

But in the vast majority of such cases I'd still use a tuple.
Where it gets  more valid is where we have deeply nested 
data structures. But then, I've never seen such a structure 
that didn't have methods too. And then it becomes a valid 
class...

> Position, with x & y attributes, for a very simple case. 

I'd use a tuple here even if p[0] is slightly less readable than p.x

> But indeed there are complex ones, possibly with nested 
> structures such as eg Point inlcluding position, color,...

In that case there will almost always be associated methods 
to be created. Even a "simple" x,y point often has comparison 
methods or draw() or move()...

> In addition, doing this helps readibility by clearly exposing 
> the object (type) structure in a single & visible place.

The visibility and naming aspect referred to above is the most 
valid reasopn I can think of for using a non behavioural class. 
But in most cases, non behavioural classes quickly become 
behavioural! After all what is the point(sic) of data if you don't 
do something to it?
 
> All of this applies both to "value" objects (pure information, 
> such as a position) and "real" objects (distinct things, such 
> as a point). What do you think?

I think that you have a valid point but that "pure value" objects 
occur far less often than you might think. I always treat a value 
object as a sign that I've probably put some processing code 
in the wrong place! Only when I've checked and convinced 
myself I'm wrong would I proceed.

For example, what do we do with the values?
Do we print them? Then maybe we should have a __str__  method?
Do we save them in a file? Then maybe we need a save() method?
Do we do some calculations? Maybe we should have a calculate() method?
Do we draw them... well, I'm sure you get the idea :-)

-- 
Alan Gauld
Author of the Learn to Program web site
http://www.alan-g.me.uk/




More information about the Tutor mailing list