Here is my solution, based on use-cases and AOP.
- you need to separate persistence from your domain
- you need to have a proper use-case, not a single request-class, like above.
- notifications are notifications (twitter, fb), they are implemented with AOP
- spam detection and language detection are separated (discussable) with an aspect.
- there is an "app" object that wraps it all together.
The first file is the original example. The second file is mine.
Flame :on
@pzol: Good question.
I would actually keep the SpamChecker and LanguageDetector as part of the use case. Only if the use case becomes too big, I'd extract it to an aspect.
As for your question, SpamChecker would have to use "around" advise instead of before. In that case it can raise SpamException. What happens after we recognize it's a spam? I don't know what's best in this case. Notify the admin to check it? It probably should be part of the SpamDetectionFeature.
Makes sense?