1

I like to know what the advantages to putting the logic in separate classes rather than putting all the logic in the RuleManager class.

For example

Separate the classes for each responsibility

class RuleManager {

    public function create(string $name)
    {
        return (new CreateRuleCommand($name));
    }


    public function list()
    {
        return new ListRulesCommand();
    }

}

vs:

class RuleManager {

    public function create(string $name)
    {
        // Do all the create logic Here

        return $something
    }


    public function list()
    {
        // Add all the listing Logic Here

        return $something
    }

}
I'll-Be-Back
  • 10,530
  • 37
  • 110
  • 213
  • what logic, where ? – tereško May 18 '17 at 20:09
  • @tereško Huh? read the the question again – I'll-Be-Back May 18 '17 at 20:10
  • 2
    This is a good question that I don't have time to answer, but in general, with the first option, you are escalating your application, meaning you only use an object that will do that for you, so you can use other new object that do the same but in different way, and in the second, only you know to do that, you will have to change that code if you want new operations to be done. – matiaslauriti May 18 '17 at 20:10
  • 3
    Well, I asked, because what I see is just a choice between tight coupling versus potential OCP violation. The "what is better" basically boils down to - which part will be changing more often and how. – tereško May 18 '17 at 20:14
  • Manager” http://stackoverflow.com/questions/1866794/naming-classes-how-to-avoid-calling-everything-a-whatevermanager :D – Chay22 May 18 '17 at 21:03

2 Answers2

0

As I see it, for this particular structure, the only benefit, that you gain by employing this type of separate classes, would be limited adherence to OCP.

That means, if one of your "commands" have to change the logic, the "Rule Manager" is not actually affected.

To be honest, I dislike both options. But use of those "command" classes comes with logic in either __construct() or __invoke() methods. That will be quite hard to test. And and they are actually really fragile. A minor change in dependencies will still meant, that your "rule manager" has to also be altered. And you have no way to extend or replace those commands, without causing similar changes.

My advice would be actually to drop the entire structure and examine, whether there is a better solution. And try not to blindly focus on design patterns, because they are not recipes, but just short-hands, to describe what you have already written.

P.S.
The "manager" in RuleManger should be pronounced as "hmmm".

tereško
  • 58,060
  • 25
  • 98
  • 150
0

There is no any advantages in the first class because commands just instantiated there. So it's possible to avoid using RuleManager easily (just by instantiating command class instead of calling create or list method). Even if we will use Factory pattern instead of direct classes creation, we still don't need RuleManager at all.

If all the methods in a class only return new instances of another classes -- without any additional logic -- probably something is wrong in the class (except some specific cases if adapter or proxy is required).

Another problem of Rule Manager is using coincidental cohesion -- methods there are probably grouped without any relations. It's worst case of cohesion (for example, you can read Steve McConnel's Code Complete) -- so it will be better to avoid it.

Generally, the major advantage of keeping logic in separate classes is changing/swapping that logic easily and of course it will decrease coupling significantly. For example, this way is extremely common when Strategy pattern is used -- so in that case, we keep the logic (strategies) in external classes, and can change particular strategy easily (of course we need to inject the strategy instead of instantiating it).

E.K.
  • 1,045
  • 6
  • 10