Хорошо, глобальная переменная осуждается, синглтон презирается, какая альтернатива?

Статический класс со статическими элементами данных? Но кого это волнует. Статические элементы данных - это просто глобальные переменные с более политкорректной упаковкой.

Не позволяйте моде преобладать над здравым смыслом. Нет ничего плохого в использовании простой старой глобальной переменной. Одноэлементный шаблон часто бывает излишним и утомляет печатать, а также раздражает, когда вы выполняете пошаговое выполнение кода для его отладки.

Предполагая, что вы используете C / C++, я бы порекомендовал вам не иметь глобальных переменных, которые являются экземплярами классов, которые выделяют память из кучи. Они усложнят вам использование инструментов, которые проверяют утечки памяти. Объявите глобал как указатель, создайте его в начале main (), удалите в конце.

ИЗМЕНИТЬ ПОСЛЕ 6 КОММЕНТАРИЙ: подумайте о ведении журнала. Разве вы не хотели бы иметь возможность записывать строку в свой журнал из любого места в вашем приложении? Насколько конкретно вы это делаете, не имея чего-то глобально видимого для ведения журнала? Если вы хотите что-то глобально видимое, сделайте это глобально видимым.

Это полностью зависит от проблемы, которую вы пытаетесь решить. Эта ключевая информация была вами упущена. Если вы ищете комплексное решение, его нет. Есть просто шаблоны, которые мы применяем, когда это возможно.

Распространенным решением этой проблемы является использование классов с одним экземпляром вместо одноэлементных / глобальных переменных.

Ваше приложение будет отвечать за то, чтобы у вас был только один экземпляр.

Это решение отстой, потому что вы не можете помешать людям создать экземпляр вашего класса (это не синглтон), поэтому он должен быть внутренним классом.

Я бы не стал слишком заботиться обо всех религиозные войны о шаблоне singleton, хотя - если я думаю, что это соответствует моим потребностям, я обычно использую его.

Мне было бы все равно, если не рекомендуются одиночные или глобальные переменные. Если мне кажется, что это наиболее логичный способ его реализации, я воспользуюсь им.

Глобальные переменные - это нормально в небольших программах, но когда они становятся больше, вы начинаете получать странные побочные эффекты, когда кто-то вносит изменения или исправляет ошибку, говоря «о, я просто установлю это глобальное, и проблема исчезнет»

Самая распространенная проблема, которую я видел как с глобальными, так и с одиночными объектами, заключается в том, что вы рискуете плохим поведением при использовании потоков. В этом случае вы всегда должны использовать область выполнения в качестве базовой единицы. Это одна из сильных сторон объектно-ориентированного программирования - вы можете использовать члены объекта для хранения всех соответствующих данных, не опасаясь случайного нарушения целостности потока. Это контрастирует с языком программирования без объектно-ориентированного программирования, где вам придется передавать данные через параметры.

Другая общая проблема, как правило, носит организационный характер - трудно понять, откуда именно поступают данные в большой системе, когда их можно прочитать / записать в любое время. По моему опыту, это проблема скорее разработчика, чем кода как такового. Если вы не работаете над одной из тех мегасистем на сто миллионов строк, которые, кажется, появляются в основном в книгах по программированию в качестве примеров сложных проблем, вы сможете искать по всей кодовой базе конкретный элемент за достаточно короткий промежуток времени. промежуток времени. Следующим необходимым шагом является регулярный аудит кодовой базы, чтобы гарантировать, что глобальные / статические переменные не назначаются случайным образом. Это проклятие для многих подходов к разработке, но для систем определенного размера и сложности это вполне работоспособное решение.

Во-первых, нет смысла делать вид, что синглы в чем-то лучше или более приемлемы, чем глобальные. Синглтон - это просто глобальный объект, одетый так, чтобы выглядеть как ООП. С кучей других проблем.

И альтернатива, конечно же, состоит в том, чтобы у нет были глобальные данные. Вместо того, чтобы ваш класс где-нибудь обращался к какой-то статической (глобальной) переменной, передайте данные ее конструктору. Да, это означает, что вам нужно добавить несколько аргументов в конструктор, но разве это плохо? Это делает зависимости для класса явными. Я могу протестировать класс, просто предоставив ему различные объекты в конструкторе, тогда как, если он полагается на глобальные данные, эти глобальные переменные должны существовать в моем тесте, что беспорядочно.

Точно так же я могу легко выполнить рефакторинг, потому что нет никаких волшебных зависимостей от классов, кроме тех, которые передаются непосредственно объекту.

Управлять безопасностью потоков становится проще, потому что все ваши объекты больше не взаимодействуют с одним и тем же глобальным экземпляром. Вместо этого им можно передавать отдельные экземпляры класса.

Ответ зависит от языка. Недавно я встретил парня, чья компания разрабатывает стек USB, который работает на многих популярных сотовых телефонах (например, чтобы ваш телефон мог разговаривать с вашим компьютером). В их магазине есть правило, согласно которому все процедуры C должны быть реентерабельными. На практике это означает, что вместо глобальных переменных они используют дополнительный параметр для каждой процедуры; параметр указывает на состояние, которое должно сохраняться между подпрограммами.

Я все время использую эту технику для абстракций с состоянием. Пример: абстракция читателя для фотографических изображений: читатель обеспечивает доступ к одному пикселю за раз; он должен знать дескриптор открытого файла, текущую позицию в изображении и т. д. и т. д. Вся эта информация передается в частную структуру C или частные члены класса C++. Нет глобальных переменных. Внешний мир видит:

typedef struct Pnmrdr_T *Pnmrdr_T;

struct Pnmrdr_T *Pnmrdr_new(FILE *);
pixel Pnmrdr_get(Pnmrdr_T);
void Pnmrdr_close(Pnmrdr_T);
void Pnmrdr_free(Pnmrdr_T *rp); // frees memory and sets *rp = NULL

Этот стиль программирования очень похож на объектно-ориентированные методы.

Почему лучше глобальных переменных? Никаких сюрпризов. Если что-то пойдет не так или вы хотите добавить функцию, вы знаете, что все явно указано в переданных значениях. Более того, вы знаете, что можете соединить множество модулей вместе, и они не будут мешать, если вы явно не передадите состояние между ними. Мой контакт в сфере сотовой связи говорит, что эта собственность очень важна для его компании - это OEM-производитель программного обеспечения, и они могут легко соединять разные части вместе для разных клиентов.

Мне очень нравится программировать таким образом, потому что я могу видеть все, что происходит, а мои личные структуры данных защищены от посторонних глаз :-)

после использования глобалов и синглтонов и увидев, что все испортилось, я пришел к этому решению.

1. сделать каждую глобальную переменную членом класса. Логически каждая глобальная переменная принадлежит приложению (или системе). просто создайте класс приложения. определять глобальные объекты как свойства. поэтому они создаются при первом вызове.

2. создайте синглтон для класса приложения, чтобы вы могли получить к нему глобальный доступ. Это будет единственный синглтон в вашем коде. ну, в конце концов, это как объекты system.out или system.in в java.

Примечание: я знаю, что это очень старый вопрос, но все еще популярный.