Comment by Mark on "Design Patterns (Service Vs Strategy)"

I'm not sure I understand the situation well enough, so apologies if this is useless.

In my opinion, strategy pattern is for things that are abstractly the same operation, but with variations that you want to choose at runtime. When I think of an API, the operations aren't usually interchangeable, so I would give them different (incompatible) types.

If you're asking whether you should split each 'operation' (API endpoint or otherwise) into it's own class, then probably yes imho. That's what I understood from the "...Strategy" postfix. That seems like something that'd make the growing of functionality more manageable.

Both ways seem like Command pattern to me (the API request being the command), but maybe I'm misunderstanding the intended use.

I feel like I'm extrapolating a lot in my interpretation, so feel free to disregard if not useful.

No you got it right, it's a command pattern utilizing a strategy which will created with a builder and since most of the needed parts are the same I refer to it as strategy since the CRUD are basically just 4 different operations on the same resource.

If I understood correctly strategy pattern are algorithmic compositions chosen by runtime? en.wikipedia.org/wiki/Strategy_pattern

The intention actually is kind of a command/strategy/flyweight pattern provided by a factory/builder/registry pattern.

I am just not sure if I over-engineer it for my sanity of isolation forcing my colleagues to obey my thoughts ;D .... I sometimes have the feeling I really throw them off with my patterns.

I just want to make it easier to actually just fix 1 thing and get closer to a function / closure that is still reusable in another context. so if we want to create a combinations of two behaviours we can actually just chain the commands together.

But you actually pretty much hit the sweet-spot of my intentions.

Still, maybe using a more simple approach will get the same results and we probably have to refactor it anyway ..... dunno .... i'm torn :)

Yeah strategy is for runtime algorithmic choices, like a different sorting criteria, dependency conflict resolver, hash function... It would probably not be considered a pattern in a functional language, just passing a function.

I think bringing it as close as possible to functions instead of classes will make it more composable and maintainable.

That might remove the need for registry too, which easily leads to mutable global state. Factory is nice if you have instances; I'm not sure what you're trying to construct. I think just functions are great for serving rest api requests, since they'll be stateless (just like rest).

Flyweight is mostly for performance. I'd skip it until there's a serious performance issue. At least I'd not base the architecture around it. JVM is pretty good at allocating and cleaning up anyway, and Rust makes flyweight hard (maybe the language tags are random).

I'm not fond of UML diagrams, but I think making some kind of drawing would help clarify, you might get more responses and/or convince/educate your colleagues :-)

Mark I am not using Java or Rust in this case, accessing just the 'create' logic by passing in the data model (shared state for flyweight) does not really makes that much difference in complexity in my head .... but that's just in my head.

Since I don't care and you got a counter argument I will go with your suggestion and keep it more along the lines of just a command / functional pattern.

Personally I would like to go more functional, but I already confuse my colleagues with OOP patterns ... and they tend to just say yes .... probably because I'm tenacious, the lead and they don't want to argue their point but work.

I am not sure if a UML will work, I use them often for myself to create a plan an rethink the functionality.

I probably will try it again tomorrow, thx a lot for your input.

Search Hashnode