If there are enough global variables, does it make sense to combine them into a separate class?

I believe that this is nonsense, because to change a variable, you need to write something like var.result ++ and so on with each variable. Is my opinion wrong?

UPD:

It is clear that in the case of 200+ variables, you need to use classes, but what about so many global variables?

 int threadCount = 4; bool bShowDebug = true; string path; fs::directory_iterator it; vector<boost::thread> threads; mutex m; atomic<long long> result(0); bool bHaveFiles = false; void f1(); string f2(); bool f3();

Closed due to the fact that it is necessary to reformulate the question so that it was possible to give an objectively correct answer by the participants αλεχολυτ , Akina , user194374, ߊߚߤߘ , fori1ton 10 Feb '17 at 13:06 .

The question gives rise to endless debates and discussions based not on knowledge, but on opinions. To get an answer, rephrase your question so that it can be given an unambiguously correct answer, or delete the question altogether. If the question can be reformulated according to the rules set out in the certificate , edit it .

  • learncpp.com/cpp-tutorial/4-2a-why-global-variables-are-evil - Suvitruf ♦
  • "to change a variable you need to write something like var.result ++" ... Specify what is the difference between global variables and variables in the global class in your opinion? - Kromster
  • four
    If you have a lot of global variables, then it means that it's time to do the separation - the variables need to be grouped by purpose. And here they need to be allocated in separate classes (or namespace). And then it turns out that some functions can also be transferred to these classes, since they work only with a given set of "variables". - KoVadim
  • one
    @Vitaly Better not to declare a lot of global variables. If you combine them, you can either put them in a separate namespace so that there are no name collisions, or if there are logical connections between variables, then put them into classes as static class members. - Vlad from Moscow
  • one
    For example, thread_count does not make sense as a global variable, it can be updated by anyone, anytime, or it may not. If you make it a private static variable of some base class for your threads (or a private variable of the thread manager), then a class will appear responsible for its relevance. A responsibility! That's what matters. - vp_arth

1 answer 1

Global variables and other singletons are bad, for obvious reasons: when there are hundreds of them in different parts of the program, they are difficult to track and very easy to break, using incorrectly.

Problem one: imagine, you are a new person in the project, you want to find some parameter whose purpose you understand and its existence is obvious, but the exact name is unknown. Let me remind you, hundreds of them throughout the project. How will you do it? Not to mention that similar logical objects will probably have variables with similar names. To solve this problem, they are clustered into namespaces and made static class fields. Similar to the way files are grouped into folders.

Problem two: there is a temptation to change data (variables) directly, bypassing the complexity of business logic. It is very easy to break the logical integrity of the data, but this error can emerge over time in a random place and its source will be VERY problematic. To solve this problem, the main property of the OOP paradigm is encapsulation. Class variables should be private, set / get methods are exposed.

And indirect problem number 3: global variables “nails” parts of the program among themselves so that it is impossible to independently test its individual parts, since will have to play very much large pieces of the environment. After that, any change in business logic is threatened by a “butterfly effect,” which may echo where you were unaware. To solve this problem, an abstraction is created from dependent data (in the form of interfaces or abstract classes), which is introduced from the outside and can easily be replaced by a test "dummy" (Mock object).

ZY Compared to these problems, having to write the name of a class to access a variable is nonsense.