Imagine, I have class IAlgo which is an interface. I have derived from him and implemented his single method called matchCount in different implementations - AlgoA1, AlgoA2, AlgoA3, AlgoB1, AlgoB2.class IAlgo{    virtual int matchCount(T1* p1, T2* p2) = 0;}class AlgoA1 : public IAlgo{    virtual int matchCount(T1* p1, T2* p2) override    {         // impl here    }}The difference between AlgoAN and AlgoBK is that category A is interested in all params of matchCount and category B is interested in only first param and the rest can be null - category B does not use them.So as an encapsulated algorithm I am using them in Strategy pattern. After some time, the product owner says that he wants a new type of algorithms (AlgoC category) that adds a new parameter to matchCount method - say T3*. So we should go back and change the whole hierarchy of IAlgo and all subclass to have the following form:    virtual int matchCount(T1* p1, T2* p2, T3* p3) = 0;This is a design problem and it seems that I had encapsulated algorithm to use it as a strategy, but it didn't work. How I have to solve this problem? Is my problem is the fact that AlgoA, AlgoB and AlgoC families are not related and they should not derive from IAlgo and they don't have IS A relationship? Should I have different interfaces IAlgoA, IAlgoB and IAlgoC for different families? Or all this is fine and I need some other solution?
Strategy pattern and Is a relationship
design;design patterns;strategy
As indicated in the comments, there is no mixed usage of algorithms from the different families.If there is no use-case where an IAlgo can refer to either an AlgoAN or an AlgoBK instance, then there is no reason to have a shared interface for the various families of algorithms.The best way forward is to introduce a new interface for each algorithm family:class IAlgoA{    virtual int matchCount(T1* p1, T2* p2) = 0;};class IAlgoB{    virtual int matchCount(T1* p1) = 0;};Then you drop the existing IAlgo interface and you fixup the locations where it was used to refer to the new family-specific interfaces.At this point, adding a third, fourth or fifth family of algorithms does not interfere with the existing families, as they don't have to conform to a shared interface any more.