-2

Im sorry in forward, Im sure I wont be able to express myself well. Its a game system:

abstract class GameType
{
    private $score;

    public __constructor($score)
    {
        $this->score = $score;
    }

    public abstract function getName();

    public function getScore()
    {
        return $this->score;
    }
}

final class Soccer extends GameType
{
    public function getName() :
    {
        return 'soccer';
    }
}

final class Basketball extends GameType
{
    public function getName() :
    {
        return 'basket ball';
    }
}

final class Hockey extends GameType
{
    public function getName() :
    {
        return 'hockey';
    }
}

this illustrates 3 kind of games, each can be scored, all has different names (I know, getName() could be replaced with constants, but lets forget it for now)

Now this seems to be fine and system-independent, lets say it's being developed by a team with FRAMEWORK A and it can be passed to another system developed by FRAMEWORK B

Until now. A new requirement, lets send an email if a score takes place:

abstract class GameType
{
    private $score;

    public __constructor($score)
    {
        $this->score = $score;
    }

    public abstract function getName();

    public abstract function notifyIfScored();

    public function getScore()
    {
        return $this->score;
    }
}

final class Soccer extends GameType
{
    public function getName() :
    {
        return 'soccer';
    }

    public abstract function notifyIfScored()
    {
        FRAMEWORK1::sendEmail('score 1');
    }
}

final class Basketball extends GameType
{
    public function getName() :
    {
        return 'basket ball';
    }

    public abstract function notifyIfScored()
    {
        FRAMEWORK1::sendEmail('score 2');
    }
}

final class Hockey extends GameType
{
    public function getName() :
    {
        return 'hockey';
    }

    public abstract function notifyIfScored()
    {
        FRAMEWORK1::sendEmail('score 3');
    }
}

sending email is tied to FRAMEWORK1, but even if we could pass it outside as Dependency Injection, its still looks like the class has to do "more" and by doing this, it looses the independence of ANY framework.

2
  • please don't cross-post: stackoverflow.com/questions/63318163/… "Cross-posting is frowned upon as it leads to fragmented answers splattered all over the network..." Commented Aug 8, 2020 at 21:38
  • 2
    “ even if we could pass it outside as Dependency Injection, its still looks like the class has to do "more" and by doing this, it looses the independence of ANY framework.” I don’t understand this comment. Can you elaborate? Commented Aug 9, 2020 at 1:20

1 Answer 1

1

Keeping the domain logic completely independent is impossible as you noted. Even your first version is not completely independent.
Yes, it is independent of the frameworks, but you have already made the choice to use software and which programming language to use. Your code cannot be used with a C++ framework without some rewriting.

So, don't fixate too much on keeping your domain logic independent of the framework that you want to use.

On the other hand, sending an email is not something that should belong in a GameType, Soccer or Basketball class. The best you could expect from those classes is that they give a notification to another class when the score changes and that other class might then decide to send an email using a particular framework. If you base the notifications on the Observer Pattern, then your domain classes don't even need to have knowledge of who might be interested in score changes.
The class sending the email doesn't have to be part of the domain logic, but could be part of the (framework-specific) application logic.

5
  • yea cool, although Observer Patterns isnt considered a good pattern. Im going to use the "Visitor Pattern" instead Commented Aug 9, 2020 at 9:36
  • 2
    @JohnSmith No pattern is good or bad in itself. It’s situational. The observer pattern is a good pattern if it’s a fitting solution for the problem at hand, otherwise it’s not a good pattern for that situation. People who say “Pattern X is bad, period.” should not be taken seriously. Commented Aug 9, 2020 at 10:33
  • 2
    @JohnSmith, where did you get it from that the observer pattern is not good? This is the first time I heard that Commented Aug 9, 2020 at 12:31
  • for example: stackoverflow.com/questions/11619680/… but if you google for "observer pattern deprecated" you find many hits, it even was deprecated in Java Commented Aug 10, 2020 at 7:26
  • 1
    @JohnSmith, that looks like a typical overreaction to over-use: The pattern is easy to apply and looks sexy, so lets use it everywhere. When problems with mis-use appear, lets ban the pattern altogether, even when there are cases where it is actually useful. Commented Aug 10, 2020 at 9:16

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.