I have few strategy class that calculate ranking. Those class implements interface with method scoreUpdates. Method scoreUpdates take two parameters( winners and lossers). Now i need add new strategies and some need more parameters. Should i add methods to base interface for this new strategy? What is best solution for this type of case?

Also I use RankingSelector service that find right strategy and returning interface. Also DI is based on this interface so i can't add new interface.

  • Is this "your own project", i.e. you are capable of fixing all breakages that result from your proposed change, and that the change wouldn't affect anyone else? If so, some of the "large scale software development" best practices don't need to apply, unless if you want to deliberately practice disciplined software development. – rwong Jan 7 at 10:28
  • Is your choice of programming language known to be a good facilitator of SOLID, in particular Interface Segregation Principle? In addition to that, does the programming language support method overloads (distinct methods having same name but different parameters)? Are these additional parameters needed for each call to scoreUpdates, or are they only needed for initialization (of the class) only? – rwong Jan 7 at 10:31
  • @rwong Programming language i used don't support method overloads. These additional parameters are needed only if user pick strategy that requires additional data to calculate result. ScoreUpdates is executed only once after game end. Strategies don't use any initialize parameters, also they are in domain layer and don't depend of anything. I have to meantion i work on own project where i want learn how to use SOLID in right way, and this is my first problem. – Patryk Siwerski Jan 7 at 10:46
  • @PatrykSiwerski: Would it be possible to set those additional parameters as initialization parameters of the relevant strategies? – Bart van Ingen Schenau Jan 7 at 11:00
  • @BartvanIngenSchenau It is possible but it will add some mess to code. I don't want strategies to keep this type of data. – Patryk Siwerski Jan 7 at 11:17

In your comment you say you want to use SOLID "in the right way".

The only thing in SOLID I know might be your problem is Open/Closed principle. Making code open towards a change is a strategic design decision. Making code open towards specific change often requires creating specific abstractions, so that change can be by just adding new code, often in form of new module/library/plugin. And making code open towards one change frequently makes it closed towards other changes. And code closed towards a change makes that change much more difficult.

In your specific case, you decided to use a Strategy pattern. This pattern makes the code open towards adding new strategies. But it makes it closed towards changing what parameters are passed to the strategies. So your problem of adding new parameter became much more complicated if you didn't add the strategy pattern. Simplest solution is to just change the abstraction and fix all the broken strategy implementations. As you control the whole project, that shouldn't be too hard. There are ways to minimize impact of this change, like IDEs with refactoring support or automated tests (that you should have written). If this strategy abstraction was published one (eg. used by projects not under your control), then that would be much more difficult.

Your Answer

By clicking "Post Your Answer", you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.