Using the Strategy standard when it affects other parts of the system

Question

... serves to define a family of algorithms, encapsulate each of them and make them interchangeable. Strategy allows the algorithm to vary regardless of the clients using it.

Okay, I get it. But come on...

Perhaps the most explicit feature of this Pattern design is the decrease of IFS within a code block. This goes according to the Open/Closed principle, right? Correct me if I’m wrong. But I could have, for example, different types of reports applied on the same data set and I wouldn’t have to add to the code every time I created a new type of report. This would eliminate the conditionals in that code snippet but I wonder if it wasn’t just a change from those conditionals 'there' to another place in the code. Makes sense?

I’m not gonna use code because it’s a more conceptual question anyway. But let’s say the user will choose the type of report to be applied in that database and will type 1, 2, 3 or 4 depending on the type of report he wants and then I pass the respective report class as parameter (report strategy) for the class that will plot this report, because before applying the pattern, say I had this selection menu in the plotting class itself. Okay, so we’re going to go back, and we could, for example, decouple the requests for each specific report and not the other way around, with a general report request and then choose which one.

Still, at some point I would have to give the user a menu of options and still use the conditional ones, no?

Answer 1

You seem to understand the pattern Strategy, motivation, etc. I don’t know if you think you should use it everywhere. There is a case that it may be better to centralize the strategies without letting anyone invent fashion in it. If you thought, know that everything depends on the real requirement.

Even if it seems like a good idea, in some cases, it’s that thing, you create the infra because it will one day need, never need me, or even you use, but if you did it in a simple way it would still be. Many of these practices that talk around are for very large projects with a very long life time and that really changes a lot. Many of these recommendations are to compensate for deficiencies in object orientation, which may indicate that the design error is lower. Remembering that I am only saying to consider this, not that I should abandon the idea of Strategy, it is very useful in several cases.

You put a very common case of a change (addition) of a strategy on one object and it reflects on another object. For example it occurs in MVC (changed something model is almost certain that it will have to change something in the view and maybe in the controller). And that’s right, you have to have a form of UI also allow adding a new strategy, perhaps using some pattern together as the Command.

Even if you do something that looks simple and you don’t have to mess with the code to put the new option in the UI, you either have to inspect the code or register that you have a new strategy to use. And in this case it may be that the UI will need some text or other information that only makes sense to it, and that should be available in the very strategy that you created, and then maybe violate the S so SOLID :) It may not be, but it’s not right for all cases, and depends on the technology used.

Alternatives

I’ve seen implementations that assemble a set of all these situations, but I don’t know if it’s a good thing, I need to test to see if it works well, I never did it to be able to talk.

An object can have everything that can be related to that strategy. In a way it’s an extension of the Strategy standard. It’s this pattern, but it takes care of more than basic strategy, it takes care of related strategies, and this is a way to have them all in one place, so you don’t forget to implement one of them.

You would have an abstract class or interface that says everything you need and each strategy implements everything. It’s exactly the standard but combined. This helps in the O’s SOLID, but violates the I and S of it.

Maybe you can make several interfaces and only in concrete say you will implement all, which no longer violates I, but if you forget to put one of the interfaces as mandatory will give problem.

Perhaps you can have the middle ground, have several interfaces and one that inherits from all and so obliges all of them (in practice will not use it anywhere but in the implementation of your class to force all strategies to be implemented without forgetting any, but pro consumo will use the individual and segregated interfaces.

Maybe create a static analysis tool to ensure everything is ok before compiling, so you can keep everything separate and have some security.

Who knows needs a unit test to ensure that all related strategies are implemented even in strategies you don’t even know yet. I don’t know if those frameworks tests have facilities for this or have to do in hand, which is not so simple, I have never done something like this.

One strategy I’ve used in a similar case was code generation, but it only works if it’s all too standardized. Reflection would also work but has a cost of Runtime that I do not like, not only for the performance, but it leaves the system less robust and prone to breaks at the time of use, although tests or static analyzers can minimize this, but always complicates, and then the generator can be better option even.

Or you can just do the convention shown in the other answer, and root for the programmer who created the new strategy to do everything right and not forget anything. It sounds bad, but there are cases that are better this way, that starting to want to make the contract too straight can complicate too much. The strategy of the previous paragraph may work in one case and not work in another, or may add complexity without real gain.

Completion

It sounds complicated, and you get stuck in a snooker and you don’t know what’s best? Welcome to the real world of software development where there are no completely correct solutions in all cases, you choose the lesser evil.