From: mat@mole-end
Subject: Re: Can functions be objects?
Summary: Transaction Records
Organization: :
Date: Wed, 22 Jul 1992 18:41:51 GMT

In article <2840@media03.UUCP>, pkr@media03.UUCP (Peter Kriens) writes:
 
> Functions as objects

> I started using OO with Smalltalk about 6 years ago.  ...  I finally
> have the feeling that today I create reasonable efficient OO models and
> designs. 
 
> Lately I am involved [with] C++ .... This ... confront[s] me with
> designs which I find very awkward. I know C++ requires a different
> design attitude. ...
 
> 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.

These aren't necessarily bad.  To begin with, think of a `transaction
record' which is needed hold the state of a transaction across several
other steps.

Actions-as-objects are often used when several objects must take active
roles, and something else must coordinate their activities, making
decisions on information that transcends the state of any of the
individual objects, or providing state store that is related to the
`process' at hand.

Id _does_ deviate from the `simulation' heritage of OO, in which the
interrelationship of object behavior is investigated--but when the
interrelationship of object behavior is to be _specified_, as it is
in engineered software, such objects have a place.
 
> 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. 

If what you need is a JUST cluster of functions, then it's probably not
a good object.  But if you need to coordinate the activities of other
objects in a shared activity, or store state information unique to the
activity, or make decisions that depend on the state of several objects
at once, you may have a good candidate for an object.
 
> 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.
 
> 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.

Often, using an object to manage a `transaction' is the only way to
bring the communication patterns under control, especially when loops
in the message flow might otherwise occur.

Also, when several activities have similar patterns, it may be possible
to share design by inheritance, and to thereby improve the program
structure.
 
> Why I post this question is to find out if these kind of objects are
> commonly regarded as good OO, and that I am standing alone, or that I am
> right. 

One thing that you MUST realize in asking questions like this is that
there are three more-or-less distinct communities using OO: Simulation,
Prototyping, and Engineered Software.  The first two are research activities;
the third a development activity.  The first two produce _results_ as
their product; the third produces a _program_ as its product.
-- 
 (This man's opinions are his own.)
 From mole-end				Mark Terribile

 uunet!mole-end!mat, Somewhere in Matawan, NJ