How can I make this more OOP
On Wed, Sep 16, 2020 at 10:28 AM sean@clipperadams.com wrote:
Stéphane Ducasse stephane.ducasse@inria.fr wrote:
refrain from using respondTo: I make code difficult to evolve and can
introduce vicious bugs.
Steph, would you say more about this? It’s something I’ve been wondering
about.
I was recently reading the Strategy pattern in the Smalltalk Companion to
the GOF book. On p. 339, they proposed the following "Smalltalk way" as an
alternative to the common class-per-strategy implementation:
[[[language=smalltalk
Composition>>repair
"Without the strategy pattern, but using perform:."
| selector |
"Construct the name of the method to invoke:"
selector := ('formatWith', formattingStrategy, 'Algorithm') asSymbol.
self perform: selector
]]]
It then dismissed the approach as "''clever but difficult from a program
understanding perspective. Even static analysis tools such as code
browsers' "senders" and "messages" fail on this code.''"
It is always best to have senders of the methods you use. Additionally,
it's far better to properly manage the user-friendly identification of a
thing and the thing itself. e.g. Plain language name mapped to a selector
or a block.
Remember, "the fact that one can do something is far different from
whether one should do that thing." (I have suffered far too often and far
too long from clever programs preferring the former without thinking about
the latter.)
It struck me as perhaps a bit extreme (i.e. too clever indeed) to construct
the algorithm selector via string concatenation. Maybe "senders" search
capabilities have gotten more sophisticated since publication, but Pharo
seems to support symbol arguments, even for e.g. message renames. I
thought, why not the following:
[[[language=smalltalk
Composition>>repair
"Without the strategy pattern, but using perform:."
self perform: self formattingStrategy
]]]
Then client code like ==aComposition formattingStrategy:
#formatWithSimpleAlgorithm== would show up in senders, message renames, etc.
But from what you’re saying, I feel I may be missing something…
respondTo: is different from a perform based on forging a selector.
respondTo: implies a different control while perform: is just sending a message.
Some logic of Spec or something else was doing respondTo: and it is an indication of weak polymorphism.
Either objects are polymorphic or they are not.
Because else you expect a behavior and because of a hidden respondTo: you get a api not invoked.
This forces you to read all the code and step to find the super cool users of respondTo:
So I really stand on my claim respondTo: should only be used in last resort.
It covers shitty design.
S.
On 16 Sep 2020, at 19:28, sean@clipperadams.com wrote:
Stéphane Ducasse stephane.ducasse@inria.fr wrote:
refrain from using respondTo: I make code difficult to evolve and can introduce vicious bugs.
Steph, would you say more about this? It’s something I’ve been wondering about.
I was recently reading the Strategy pattern in the Smalltalk Companion to the GOF book. On p. 339, they proposed the following "Smalltalk way" as an alternative to the common class-per-strategy implementation:
[[[language=smalltalk
Composition>>repair
"Without the strategy pattern, but using perform:."
| selector |
"Construct the name of the method to invoke:"
selector := ('formatWith', formattingStrategy, 'Algorithm') asSymbol.
self perform: selector
]]]
It then dismissed the approach as "''clever but difficult from a program understanding perspective. Even static analysis tools such as code browsers' "senders" and "messages" fail on this code.''"
It struck me as perhaps a bit extreme (i.e. too clever indeed) to construct the algorithm selector via string concatenation. Maybe "senders" search capabilities have gotten more sophisticated since publication, but Pharo seems to support symbol arguments, even for e.g. message renames. I thought, why not the following:
[[[language=smalltalk
Composition>>repair
"Without the strategy pattern, but using perform:."
self perform: self formattingStrategy
]]]
Then client code like ==aComposition formattingStrategy: #formatWithSimpleAlgorithm== would show up in senders, message renames, etc.
But from what you’re saying, I feel I may be missing something…
Stéphane Ducasse
http://stephane.ducasse.free.fr / http://www.pharo.org
03 59 35 87 52
Assistant: Aurore Dalle
FAX 03 59 57 78 50
TEL 03 59 35 86 16
S. Ducasse - Inria
40, avenue Halley,
Parc Scientifique de la Haute Borne, Bât.A, Park Plaza
Villeneuve d'Ascq 59650
France