CODEWITHSUNDEEP
smalltalk
wirrbel
wirrbel

Reputation: 3299

Questionable Method: How to port code using overloaded method to (pharo) smallltalk

I am trying to port some statically typed OOP code over to Smalltalk which performs some kind of event sourcing. I think it will in the end look a bit like this if I continue the way I do.

EventAgg>>processEvent: anEvent
    "I can process an event"

    (anEvent isKindOf: Discarded)
        ifTrue: [ self discard ]
        ifFalse: [ "...." ]

```

Pharo's built-in linter complains about usage of isKindOf ("Sends 'Questionable' message"). I can understand the reasons, most of the time one would want to use polymorphism instead of explicit conditionals. But since the processing code accesses private states of the EventAgg class it doesn't make much sense to call out to the event, only to send an event-specific message back to the EventAgg class to process the event.

Are there any patterns for this in Smalltalk that I don't know about?

Upvotes: 3

Views: 203

Answers (2)

Leandro Caniglia
Leandro Caniglia

Reputation: 14858

You are not exposing enough of your design as to let us provide a precise answer. So, let me suggest a couple of general approaches for you to decide which one (if any) will work better in your case.

The obvious one is double dispatching, which you seem inclined to discard (don't know why):

EventAgg>>processEvent: anEvent
  anEvent beProccessedWith: self

Discarded >> beProccessedWith: anEventAgg
  anEventAgg processDiscardedEvent: self

EventAgg>>processDiscardedEvent: anEvent
  self discard

However, before using this pattern, I would explore other ways of collaboration such as:

EventAgg>>processEvent: anEvent
  anEvent beProccessedWith: self

Discarded >> beProccessedWith: anEventAgg
  anEventAgg discard

This second approach will create more cohesion but could make sense if you think it is natural for your objects to do some teamwork. More complex events may require the involvement of both objects. Of course, you will need to pay more attention when assigning responsibilities. Specifically, I would try to avoid code where, say, the Event knows too much about the internals of the EventAgg. To do this let the Event delegate specific tasks to the EventAgg whenever appropriate. Something on the lines of

EventAgg>>processEvent: anEvent
  anEvent beProccessedWith: self

ComplexEvent >> beProccessedWith: anEventAgg
  anEventAgg
    doThisUsing: self thisInformation;
    doThatUsing: self thatInformation

Upvotes: 4

Johan B
Johan B

Reputation: 2471

You can use the pattern known as Double dispatch. This technique is used to implement method overloading in Smalltalk.

See this post on double dispatch in Pharo Smalltalk

Upvotes: 2

Related Questions