For the correct OOP solution, you would need consider whether this can be thought of as a kind of stateless leaf method, and therefore implement it as an abstract (singleton) factory, but on the other hand, if you’re using a context object with the registry pattern, you should probably do this properly with IoC containers. Of course, if your object graph isn’t too complex or entangled, you could always just do constructor injection but you risk manging your unit tests, so I would go cautiously if I were looking in that direction.
Shouldn’t there be a call to the boolean comparison microservices server in there somewhere? Also, we should consider the possibility that booleans and their operators could be overloaded to do something else entirely. We might need a server farm to handle all of the boolean comparison service requests.
You’re right, this is just not oop AT ALL.
For the correct OOP solution, you would need consider whether this can be thought of as a kind of stateless leaf method, and therefore implement it as an abstract (singleton) factory, but on the other hand, if you’re using a context object with the registry pattern, you should probably do this properly with IoC containers. Of course, if your object graph isn’t too complex or entangled, you could always just do constructor injection but you risk manging your unit tests, so I would go cautiously if I were looking in that direction.
I love how OOP devolves into shoving code up it’s own ass.
I was just thinking it needed more factories
What about a factory for the factories! There’s nothing more efficient than a tool making tool making tool.
Shouldn’t there be a call to the boolean comparison microservices server in there somewhere? Also, we should consider the possibility that booleans and their operators could be overloaded to do something else entirely. We might need a server farm to handle all of the boolean comparison service requests.
You’re so right, I didn’t think of that. Maybe I’m not cut out to be a manager in IT.