>
> It depends on the current level of abstraction. If you are operating at a
> much higher level, say transfering
> money between two accounts, you would do:
>
#transferMoney from: aPayer to: aPayee
> where both aPayer and aPayee could be anAccountHolder
Why not
#transferMoney from: payerAccountHolder to: payeeAccountHolder
?
And how does the naming depend on level of abstraction?
Practically, when a (potential) user of the method is going to invoke it,
one of the first questions will be 'what kind of object I can/should pass
there?'. With the classic Smalltalk convention it is quite obvious (though,
the convention is not perfect itself and sometimes/often is not enough).
With the aPayer and aPayee the user will have to read the method code to
learn that.
--
Best regards,
Dennis Schetinin
чт, 12 июл. 2018 г. в 6:29, K K Subbu <kksubbu...@gmail.com>:
> On Thursday 12 July 2018 03:54 AM, Tim Mackinnon wrote:
> > I was taught {“a”/“an”}DataType, so it would be:
> >
> > #name: aString
>
> It depends on the current level of abstraction. At the lowest levels, it
> is okay to use basic types like aString since classes (types) define
> behavior. If you are operating at a much higher level, say transfering
> money between two accounts, you would do:
>
> #transferMoney from: aPayer to: aPayee
>
> where both aPayer and aPayee could be anAccountHolder
>
> Essentially, the idea to keep the message part as close to normal
> statements as possible.
>
> The book "A Mentoring Course Smalltalk" by Andres Valloud covers this
> aspect in great detail.
>
> Regards .. Subbu
>
>
>
