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.
SOLVED.
On reflection, @collapse_already@lemmy.ml has come up with the perfect solution - let me explain,
YES. We should utilise a microservices architecture so that we can leverage a fundamental distributed interconnected parallelism to these boolean comparisons which is bound to beat single-thread, single-core calculation hands down. Already. But it gets better. Of course a load balancing microservice would be useful because you don’t want one of the boolean comparison microservices accidentally taking too great a share of the computation, making the whole topology more brittle than it needs to be. A boolean comparison request-comparing analytics microservice could evaluate different request distribution heuristics to the individual microservice nodes (for example targetting similar requests resolving to true/true or false/true etc versus fair-balancing-oriented server targetting versus pseudo-random distribution etc etc), and do so for randomly selected proportions of the uptime. The incoming boolean comparison requests would be tagged and logged for cross-reference and analysis, together with the computation times, current request-distribution heuristic and selected server so that each heuristic can be analysed for effectiveness in different circumstances. In fact, the simplest way of evaluating the different heuristic pragmas would be to input the aforementioned boolean comparison request logs, together with some general data on time of day/week/year and general performance metrics, into a neural network with a straightforward faster-is-better training programme, and pretty soon you’ll ORGANICALLY find the MOST EFFICIENT way of managing the boolean comparison requests.
We can calculate the most efficient solution, folks. PROBLEM SOLVED.
There’s literally nothing related to OOP in this snippet.
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.
SOLVED. On reflection, @collapse_already@lemmy.ml has come up with the perfect solution - let me explain,
YES. We should utilise a microservices architecture so that we can leverage a fundamental distributed interconnected parallelism to these boolean comparisons which is bound to beat single-thread, single-core calculation hands down. Already. But it gets better. Of course a load balancing microservice would be useful because you don’t want one of the boolean comparison microservices accidentally taking too great a share of the computation, making the whole topology more brittle than it needs to be. A boolean comparison request-comparing analytics microservice could evaluate different request distribution heuristics to the individual microservice nodes (for example targetting similar requests resolving to true/true or false/true etc versus fair-balancing-oriented server targetting versus pseudo-random distribution etc etc), and do so for randomly selected proportions of the uptime. The incoming boolean comparison requests would be tagged and logged for cross-reference and analysis, together with the computation times, current request-distribution heuristic and selected server so that each heuristic can be analysed for effectiveness in different circumstances. In fact, the simplest way of evaluating the different heuristic pragmas would be to input the aforementioned boolean comparison request logs, together with some general data on time of day/week/year and general performance metrics, into a neural network with a straightforward faster-is-better training programme, and pretty soon you’ll ORGANICALLY find the MOST EFFICIENT way of managing the boolean comparison requests.
We can calculate the most efficient solution, folks. PROBLEM SOLVED.