Класс с переменными [требует правки]

260

11 февраля 2017, 07:53

Если глобальных переменных достаточно много, имеет ли смысл объединять их в отдельный класс?

Я считаю, что это бред, ибо чтобы изменить переменную нужно писать что-то типа var.result++ и так с каждой переменной. Ошибочно ли моё мнение?

UPD:

Понятно, что в случае с 200+ переменных нужно использовать классы, но что насчёт такого количества глобальных переменных?

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();

Answer 1

Глобальные переменные и прочие синглтоны - это плохо, по понятным причинам: когда их сотни по разным частям программы, то их сложно отслеживать и очень легко поломать, используя неверно.

Проблема первая: представьте, вы - новый человек в проекте, хотите найти какой-то параметр, назначение которого вам понятно и его существование очевидно, но точное имя неизвестно. Напомню, их сотни по всему проекту. Как вы это будуте делать? Не говоря уже о том, что у похожих логических объектов наверняка будут переменные с похожими именами. Для решения этой проблемы их кластеризуют в пространства имен и делают статическими полями классов. Аналогично тому, как файлы группируют по папкам.

Проблема вторая: есть соблазн менять данные (переменные) напрямую, в обход сложностей бизнес-логики. Так очень легко сломать логическую целостность данных, а ошибка эта может всплыть через время в случайном месте и ее источник определить будет ОЧЕНЬ проблематично. Для решения этой проблемы используется основное свойство парадигмы ООП - инкапсуляция. Переменные классов должны быть приватными, наружу выставляются методы set/get.

И косвенная проблема №3: глобальные переменные "прибивают гвоздями" части программы между собой так, что невозможно независимо тестировать ее отдельные части, т.к. придется воспроизводить очень уж большие куски окружения. После этого любое изменение в бизнес-логике грозит "эффектом бабочки", которое может отозваться эхом там, где вы и не подозревали. Для решения этой проблемы создается абстракция от зависимых данных (в виде интерфейсов или абстрактных классов), которая внедряется извне и легко может быть подменена тестовой "пустышкой" (Mock object).

З.Ы. В сравнении с этими проблемами, необходимость писать имя класса для доступа к переменной - это ерунда.

ПОСЛЕДНИЕ ВОПРОСЫ

Все вопросы

ТОП-10

Все популярные вопросы

Релиз программы

Пишу программу для windows(xp,7,8,10)

243

c++

Нестандартный синтаксис

Выдаёт ошибку, указывая на boost::thread "нестандартный синтаксис; используйте "&", чтобы создать указатель на член"Что нужно исправить? Если указать...

669

c++

Как передать CredHandle дочернему процессу?

Добрый день

272

c++

Убрать лишние пробелы и табы в std::string строке

Допустим есть строка с именем процессора, которую возвращает функция GetProcessorName():

313