2

Strategy pattern solves the necessity of applying a certain algorithm/behaviour depending on the object's type itself. So you can iterate over a bunch of similar objects and call the same function expecting different algorithms to be executed for each one.

But what about two (or more) objects may have a special algorithm for them together? Only if they both are in our list to iterate. If not, they have their own single object behaviour.

Example:

We have different object types: Blue, Yellow and Red. They all have their own shine() method, which implements from its own strategy: BlueShineStrategy, YellowShineStrategy and RedShineStrategy.

Then I have a combination of Blue and Yellow objects. In order to make them shine, I'll do:

combination = [blueObject, yellowObject]
for c in combination:
   c.shine()

That's okay. The problem comes when a restriction is added. If Red and Blue are present in the combination, I cannot call the shine method for everyone, I must use, just for those two, a RedBlueShineStrategy.

When is the time to ask and decide the use of the combined strategies? Is it in the moment of execution (the for moment)?

Or should I decide this before? (considering I can model the combinations, I can have an array of "special groups" included in the model)

JorgeDLuffy
  • 29
  • 2
  • I would think that you'd have a RedBlue object with its own shine method. I do understand how that might cause a combinatorial explosion of new classes. It doesn't have to be a variation on the Strategy pattern or even look like the Strategy pattern if it's not a good fit. – Robert Harvey May 02 '18 at 17:31
  • 2
    That... isn't the strategy pattern. I mean, the strategy pattern is part of this - but a strategy doesn't care about types. It's just an approach where behavior is a replaceable component. – Telastyn May 02 '18 at 18:00
  • Sure, the RedBlue object will have its own shine method. I agree, this looks like Strategy Pattern, but starts to be something different. It looked like the best approach at the beginning, before the combination problem. The issue now is how to implement it in a scalable way. Or, as you say, if this is not the right pattern/strategy to follow – JorgeDLuffy May 02 '18 at 18:06

2 Answers2

1

I think the problem is in the name. Calling it RedBlueShineStrategy is too specific. Perhaps MultiColorShineStrategy works better, because you are dealing with the abstraction of multiple colors. This could take an array or colors and it just shines them all.

So I suppose combining the strategy pattern with the composition pattern would work.

Greg Burghardt
  • 34,276
  • 8
  • 63
  • 114
  • The problem is the need of being that specific. It will exist another RedYellowStrategy, that may be different to the others combined strategies – JorgeDLuffy May 03 '18 at 06:25
1

I think the pattern you want is Visitor. In essence, you need something to operate on an aggregate. So. If you have a hierarchy or collection of things, have a ShineVisitor visit your aggregate. This will allow you to shine through filters for example.

Sentinel
  • 432
  • 3
  • 10