Opinions always differ on matters like this, but your UserService class seems
like a severe case of over-engineering.
First, three of the methods seem to offer nothing very substantive:
desactivate_user() and reactive_user() just set boolean attributes on a
User instance; and is_active() just returns an attribute. I would encourage
you to simplify things: ...
Bug: on the first line of run_script, SCRIPT.items() should be script.items(). As written, it executes the global SCRIPT and not the argument to the function.
It doesn't seem like Agent should inherit from Driver
If you research Selenium best practices, you will find a few that make sense for your use case (most are geared toward testing). Two of them are ...
I don't think you need to test everything around opening the input file, closing it, handling exceptions, etc. For the purpose of this task, I believe you want to test your logic, and trust that FileReader or FileInputStream etc just work.
I would have a class that that can read the format of the dictionary (not provided, presumably this is ...
Don’t use #pragma once. It’s non-standard, it breaks silently and unexpectedly and when it does all hell breaks loose, and the standard solution (include guards) are just as efficient in practice.
const int g_MaxNumberOfObjectsInPool = 2;
There doesn’t seem any good reason why this should be a global variable. It would be better as a static ...
When I see pointers in a class and/or struct in my mind comes e serious potential for memory leaks unless a careful implementation has been considered.
Since you would like comments on how to make this code closer to a production-level code, avoiding memory leaks is definitely a very important aspect.
I will explain myself using an example:
Let's say a ...
You don't need to write ...ifNecessary if you just describe the property you want to have in the return value, and then you just know that after calling it, it has that property. You want the return amount to be clamped so it is less than or equal to the maximum amount. It doesn't matter that it might not change it, but it DOES matter to the business logic ...
The short answer is: You don't need the strategy pattern here. just do as nullTermiator said in his answer.
To understand why strategy does not fit here, first we need to understand the problem strategy supposed to solve, or formally, the intention of the strategy pattern.
In statically typed languages such as Java, C#, Kotlin, etc. you can't simply use two ...
Few things I noticed
It is good practice to make methods as getters const
Setting values in a destructor
No reason that I am aware of to do pageAr = nullptr; pageCount = 0; during destruction.
Range-based for loop
They are less error-prone (you can't mess up with indices) so I would suggest using them if possible
Some preliminary observations to get you started:
Since Disk and Cache aren't memory management classes, do not
write your own memory management code, since C++ memory management is
error-prone. Instead, use standard library facilities like
std::vector whenever possible.
This always copies the argument:
void setContent(const std::...