Re: Yet another stupid question...
Re: Yet another stupid question...
- Subject: Re: Yet another stupid question...
- From: Simon Stapleton <email@hidden>
- Date: Fri, 07 Dec 2001 10:14:33 +0000 (GMT)
>
Subject: Yet another stupid question...
>
From: Martin Kautz <email@hidden>
>
To: "email@hidden" <email@hidden>
>
>
Hello list,
>
>
this time it's about functions (at least what I would consider as
>
functions).
<snip>
>
P.S. Forgive me, if this is too stupid for this list.
Not at all.
The difference is a conceptual one, and I would refer you to Kent
Beck's "Smalltalk best practice patterns" as recommended on this list
recently.
The concept is known as 'intention revealing selectors' - or for
those mired in C/C++/PHP 'function calls that tell you what they do'
Note - I will be using 'method' rather than 'selector' below, no
flames please I'm trying to avoid confusion.
Let's ignore the trivial math example, and look at something a bit
more real-world (for math, you'd generally just use straight C in
most cases)
Here I paste verbatim the function declaration from some C++ I'm
currently working on (note, I didn't write this code), which defines
the interface to a method that calculates the value of a cashflow
which needs to be settled on a financial swap.
dm_money calculate (dm_date&, dm_date&, dm_date&, observationset*);
This, of course, is meaningless without comments. It could (and
should) have been written as :
dm_money calculate (dm_date& paymentDate,
dm_date& startDate,
dm_date& endDate,
observationset* rateObservations);
This tells you a lot more about what the method does, and is much
better practice.
In Obj-C, we might write (without the redesign the app so richly
deserves, and assuming the dm_xxx types are typedefs to simple C
types) :
- (dm_money) cashflowValueAt: (dm_date) paymentDate
withPeriodStartDate: (dm_date) startDate
endDate: (dm_date) endDate
rateObservations: (NSArray *) observations;
Now, it might appear that this is not really so different from the
second of the C++ examples, until you realise that the name of this
method is
'cashflowValueAt:withPeriodStartDate:endDate:rateObservations:'
Which, although a bit verbose, shows the intention of the method,
as opposed to the C++ version, which is simply
'calculate'
If you are careful with method names, they can be a valuable pointer
as to where your design is going wrong. Ask yourself 'does this make
sense in the context of class xxx?'
And yes, in most cases, having a method that takes umpteen parameters
is a design flaw. But let's not get into a flame war about that.
Simon
--
PGP Key ID : 0x50D0698D
--
If the answer isn't obvious, the question is a distraction. Go find
an easier question.