Использовать ли глобальные переменные для конфигов в golang?

Question

[lelvisl]

Как правильнее - записывать структуру конфига в глобальную переменную, и дергать его из всех функций, или записывать его локально, и передавать указатель в каждую функцию, которая использует параметры из него?

Comments

[Александр Павлюк]

Второе удобнее для тестирования, а первое для разработки.

[lelvisl]

Александр Павлюк , вопрос - где я теряю меньше ресурсов?

[Александр Павлюк]

lelvisl: теряете меньше ресурсов в варианте с глобальной переменной. Ибо меньше указателей, меньше мусора, меньше работы для GC.

[Oleg Shevelev]

lelvisl: если будете передавать конфиг в каждую функцию то посмотрите на то что бы передавать конфиг в пакет в одном месте, а уже в рамках пакета использовать внутреннюю переменную. Указатель или обычную - это уже как решите.

Answer 1

[Никита]

Глобальная (а точнее публичная в отдельном пакете для удобства) переменная используется очень часто, но это в тех случаях, когда вы не будете программно менять значение переменной. Если же значения в переменной будут меняться программно - то придётся дописать модуль, чтоб там была не только 1 переменная (уже закрытая), а пару публичных методов с мьютексами или работой с каналами - как вам удобно.

Comments

[Александр Павлюк]

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

[Oleg Shevelev]

Никита: Так же надо указать что работа с каналами будет превращать доступ к данным из многотопочного в однопоточный и в случае если конфиг большой и его нужно скажем весь обновить могут быть долгие локи если об этом не позаботиться заранее, но в целом вы правы указав эти варианты:)

Answer 2

[Oleg Shevelev]

Вот вопросы которые возникают при написании движка для конфигов:

• количество копий данных
  
• конкуентный доступ (что если программа должна будет обновлять часть конфига на лету)
  
• сохранение конфига на диск в случае изменения программой и мердж с уже имеющимся конфигом на диске в случае если он уже был изменен в ручную и не был загружен приложением до момента мерджа
  
• доступ из нескольких пакетов (как правило тех где бизнес-логика, а не универсальных библиотек)
  
• формат хранения данных, xml, json, ini или любой другой вариант, включая базу данных
  
• своевременное обновление конфига при изменении из вне. С перезагрузкой приложения, без перезагрузки в автоматическом режиме (программа сама отслеживает изменился ли файл конфига) в режиме получения сигнала на то что конфиг нужно перечитать.
  

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

Идеального конфига под Golang пока не видел, но есть очень интересные.

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

Некоторые конфиги работающие по принципу "возьмём файл и скиним его на структуру" в этом случае не работают потому что структура не совпадает. А не совпадать она может очень часто, потому что клиентам и их сотрудникам заранее не известно что это очень чувствительное место программы.

Comments

[Александр Павлюк]

Ни один из этих вопросов не влияет на выбор "глобальная переменная vs dependency injection"

[Oleg Shevelev]

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

[Oleg Shevelev]

Александр Павлюк: к примеру вы выбрали глобальные переменные - что будете делать с конкуретным доступом? Может быть сейчас вас устроит:
1. записать данные в переменную в func init()
2. везде и всюду только читать

Но пройдёт какое-то время и вам захочется туда чего-нибудь записать. Или ещё чего.

[Александр Павлюк]

Oleg Shevelev: переменная это просто хранилище для объекта конфига. У этого объекта будут потокобезопасные методы для доступа к параметрам. Вообще без разницы как при этом передается объект, через глобальную переменную или через параметр функции.

[Oleg Shevelev]

Александр Павлюк: вы топикпастер? Откуда вам знать что у него там за объект и потокобезопасно ли:)

Суть моего ответа в том что бы последующие вопрошающие по теме были более осведомлены о том с какими вопросами им придётся столкнуться.

[Александр Павлюк]

Oleg Shevelev: допустим, объект у него не потокобезопасен. Тогда, передавая указатель в функцию, он столкнется с такими-же проблемами, как в случае с глобальной переменной.