From: knight@mrco.carleton.ca (Alan Knight)
Subject: Re: Can functions be objects?
Reply-To: knight@mrco.carleton.ca (Alan Knight)
Organization: Carleton University
Date: Mon, 27 Jul 1992 13:41:06 GMT

In <2840@media03.UUCP> pkr@media03.UUCP (Peter Kriens) writes:

>However, I get the uneasy feeling that I am missing
>something because everybody else seems to find function objects
>which I regard as bad. Even in the book of Rebecca Wirfs-Brock 
>I am confronted with an Inquiry, a Deposit and a Withdrawal object
>in the ATM. In a design I am reviewing I find a XX_Create, XX_Delete 
>and a XX_Edit object.

>My personal feeling is to immediately reject these kind of objects
>because they feel like they were found from structured analysis
>instead of object oriented analysis. They could be there because
>people need an abstraction mechanism to collect together a group
>of functions, and that is what they call a class. 

>I feel strongly that an object should play an active rol in the
>problem domain. The Inquiry or Withdrawal are not tangible things,
>but just services executed by "something". By definition, the Inquiry, 
>the Withdrawal etc. will be closely tied together, because they will
>use the same kind of input/output devices and basic services.

It seems to me that there is a considerable difference between "plays
an active role in the problem domain" and "are tangible things". The
different kinds of transactions certainly play an important role in
the domain. They just aren't tangible. I think that trying to restrict
objects to things that can be picked up and thrown is a bad idea. 

It's certainly true that objects representing functions can be a
symptom of bad design, but they can also be a very good thing.  I
personally think XX_Create, XX_Edit etc. sounds suspicious, whereas
Inquiry, Withdrawal, etc. sound pretty reasonable.

IMHO, if you can give something a reasonable name then it's a good
candidate for an object. XX_Create probably isn't a reasonable name
for an object because it sounds too much like a method name. On the
other hand XX_Reader, which reads objects of type XX from a file,
might be (depends how complicated reading is, and whether it's
possible to write a general File_Reader). 

This is true whether the thing you are naming is tangible or not.
Consider another example, Colour. Colour is not a concrete thing in
itself, it's just an attribute belonging to some other thing. Would it
be ridiculous to make Colour an object in its own right? I don't think
so. 

You point out that Inquiry and Withdrawal will have much in common.
This is true, but argues that they should probably both be subclasses
of the abstract class Transaction, as much as it argues for them to be
methods. 

>Seperating these into a seperate class makes the communication pattern
>needlessly complex. And the fact the the person who wants to understand
>the program needs to understand more classes, will increase maintenance
>cost.

True, but taking something with a complicated functionality and
spreading it out into one or more places it doesn't belong is also a
bad thing. This is a matter of design, and is true whether you're
dealing with objects that are tangible or not. 

-- 
 Alan Knight  knight@mrco.carleton.ca  +1 613 788 2600x5783   Join
 Dept. of Mechanical and Aerospace Engineering                the
 Carleton University, Ottawa, Ontario, Canada, K1S 5B6        LPF

Xref: sparky comp.object:3086 comp.specification:337