I really HATE service objects. Lets have a look at a recent article.
http://www.jaredrader.com/technical/2018/08/21/from-service-objects-to-interactors/
This implementation of that logic has some really simple flaws. Lets forget about the issue with basics like, where does the @sender come from.
Can you answer the following questions?
- What happens if a user wants to be notified by some other mechanism but email?
- What if either of the users (recipient, sender) does not want to be notified?
- What happens when the implementation of how reward points are recorded is changed?
- When inserting a record of a survey, WHY do you even care if there is some sort of reward system?
If you want to change how a user is notified, all of a sudden you have to change every service object that sends any sort of notification.
Instead, the User model should have a method to ‘receive_notification’ and deal with it in a decent OO way.
Similarly, the User object should be told it has received reward points and decide how to record that itself.
Why not trigger adding the reward points from the creation of the survey response? why does this have to be bound into the ACTION?
Spreading out all this model logic within your service objects leads you to duplicate it. For goodness sake, instead adopt a decent MESSAGE PASSING architecture.
Tell your model objects what has happened, don’t tell them what to DO about it. Let them COOPERATE in achieving the outcome desired. ISOLATE, don’t AMALGAMATE.
Over time your service objects grow in complexity and become a sink for shadow behaviour that SHOULD be in your models.