Return to Answer

Does this pattern have a name,

That depends on who you ask. Some folk treat patterns as only applicable to OOP and see them as more like implementation patterns in that, for example the UML used in the GoF book, lays out what the pattern looks like. If you are of that view, then no it's not a pattern.

If you take a broader view that a pattern describes a design concept and isn't interested in the implementation (to me the clue is in the name "design pattern" here) then yes, you are using the strategy pattern. Quoting from Wikipedia, "[it is] a software design pattern that enables selecting an algorithm at runtime. Instead of implementing a single algorithm directly, code receives run-time instructions as to which in a family of algorithms to use"

and is it considered an anti-pattern?

Not as you show it. You have one function that matches against the enum values and picks a function to call (ie it implements the strategy pattern). What you have there is good: it's simple, easy to understand and easy to maintain. I'd maybe move the enum to within WebService as it keeps the enum and the decision tree in one place, but that's the only improvement I'd suggest here.

However, the moment you create another function, elsewhere in the code, that also matches against those enum values and picks a function to call, you start to cause problems for yourself. If you change the enum, you have to remember to change the decision tree in two places. Add a third, fourth, etc. place and the code quickly becomes a maintenance nightmare. And that is how this approach can become an anti-pattern.

Does this pattern have a name,

That depends on who you ask. Some folk treat patterns as only applicable to OOP and see them as more like implementation patterns in that, for example the UML used in the GoF book, lays out what the pattern looks like. If you are of that view, then it's not a pattern.

If you take a broader view that a pattern describes a design concept and isn't interested in the implementation (to me the clue is in the name "design pattern" here) then yes, you are using the strategy pattern. Quoting from Wikipedia, "[it is] a software design pattern that enables selecting an algorithm at runtime. Instead of implementing a single algorithm directly, code receives run-time instructions as to which in a family of algorithms to use"

and is it considered an anti-pattern?

Not as you show it. You have one function that matches against the enum values and picks a function to call (ie it implements the strategy pattern). What you have there is good: it's simple, easy to understand and easy to maintain. I'd maybe move the enum to within WebService as it keeps the enum and the decision tree in one place, but that's the only improvement I'd suggest here.

However, the moment you create another function, elsewhere in the code, that also matches against those enum values and picks a function to call, you start to cause problems for yourself. If you change the enum, you have to remember to change the decision tree in two places. Add a third, fourth, etc. place and the code quickly becomes a maintenance nightmare. And that is how this approach can become an anti-pattern.

Does this pattern have a name,

That depends on who you ask. Some folk treat patterns as only applicable to OOP and see them as more like implementation patterns in that, for example the UML used in the GoF book, lays out what the pattern looks like. If you are of that view, then no it's not a pattern.

If you take a broader view that a pattern describes a design concept and isn't interested in the implementation (to me the clue is in the name "design pattern" here) then yes, you are using the strategy pattern. Quoting from Wikipedia, "[it is] a software design pattern that enables selecting an algorithm at runtime. Instead of implementing a single algorithm directly, code receives run-time instructions as to which in a family of algorithms to use"

and is it considered an anti-pattern?

Not as you show it. You have one function that matches against the enum values and picks a function to call (ie it implements the strategy pattern). What you have there is good: it's simple, easy to understand and easy to maintain. I'd maybe move the enum to within WebService as it keeps the enum and the decision tree in one place, but that's the only improvement I'd suggest here.

However, the moment you create another function, elsewhere in the code, that also matches against those enum values and picks a function to call, you start to cause problems for yourself. If you change the enum, you have to remember to change the decision tree in two places. Add a third, fourth etc places and the code quickly becomes a maintenance nightmare. And that is how this approach can become an anti pattern.

Does this pattern have a name,

That depends on who you ask. Some folk treat patterns as only applicable to OOP and see them as more like implementation patterns in that, for example the UML used in the GoF book, lays out what the pattern looks like. If you are of that view, then no it's not a pattern.

If you take a broader view that a pattern describes a design concept and isn't interested in the implementation (to me the clue is in the name "design pattern" here) then yes, you are using the strategy pattern. Quoting from Wikipedia, "[it is] a software design pattern that enables selecting an algorithm at runtime. Instead of implementing a single algorithm directly, code receives run-time instructions as to which in a family of algorithms to use"

and is it considered an anti-pattern?

Not as you show it. You have one function that matches against the enum values and picks a function to call (ie it implements the strategy pattern). What you have there is good: it's simple, easy to understand and easy to maintain. I'd maybe move the enum to within WebService as it keeps the enum and the decision tree in one place, but that's the only improvement I'd suggest here.

However, the moment you create another function, elsewhere in the code, that also matches against those enum values and picks a function to call, you start to cause problems for yourself. If you change the enum, you have to remember to change the decision tree in two places. Add a third, fourth, etc. place and the code quickly becomes a maintenance nightmare. And that is how this approach can become an anti-pattern.

Does this pattern have a name,

That depends on who you ask. Some folk treat patterns as (a) only applicable to OOP and (b) more like implementation patterns in that eg the UML used in the GoF book lays out what the pattern looks like. If you are of that view, then no it's not a pattern.

If you take a broader view that a pattern describes a design concept and isn't interested in the implementation (to me the clue is in the name "design pattern" here) then yes, you are using the strategy pattern. [Quoting from Wikipedia]https://en.wikipedia.org/wiki/Strategy_pattern(), "[it is] a software design pattern that enables selecting an algorithm at runtime. Instead of implementing a single algorithm directly, code receives run-time instructions as to which in a family of algorithms to use"

and is it considered an anti-pattern?

Not as you show it. You have one function that matches against the enum values and picks a function to call (ie it implements the strategy pattern). What you have there is good: it's simple, easy to understand and easy to maintain. I'd maybe move the enum to within WebService as it keeps the enum and the decision tree in one place, but that's the only improvement I'd suggest here.

However, the moment you create another function, elsewhere in the code, that also matches against those enum values and picks a function to call, you start to cause problems for yourself. If you change the enum, you have to remember to change the decision tree in two places. Add a third, fourth etc places and the code quickly becomes a maintenance nightmare. And that is how this approach can become an anti pattern.

Does this pattern have a name,

That depends on who you ask. Some folk treat patterns as only applicable to OOP and see them as more like implementation patterns in that, for example the UML used in the GoF book, lays out what the pattern looks like. If you are of that view, then no it's not a pattern.

If you take a broader view that a pattern describes a design concept and isn't interested in the implementation (to me the clue is in the name "design pattern" here) then yes, you are using the strategy pattern. Quoting from Wikipedia, "[it is] a software design pattern that enables selecting an algorithm at runtime. Instead of implementing a single algorithm directly, code receives run-time instructions as to which in a family of algorithms to use"

and is it considered an anti-pattern?

Not as you show it. You have one function that matches against the enum values and picks a function to call (ie it implements the strategy pattern). What you have there is good: it's simple, easy to understand and easy to maintain. I'd maybe move the enum to within WebService as it keeps the enum and the decision tree in one place, but that's the only improvement I'd suggest here.

However, the moment you create another function, elsewhere in the code, that also matches against those enum values and picks a function to call, you start to cause problems for yourself. If you change the enum, you have to remember to change the decision tree in two places. Add a third, fourth etc places and the code quickly becomes a maintenance nightmare. And that is how this approach can become an anti pattern.