Опишите свою борьбу с уменьшением использования [закрытых] глобальных переменных
2 ответа
Я думаю, что есть время и место для шаблона singleton или подобных ситуаций. Главное помнить, что снова и снова многие люди испытывают конкретный ужас, когда дело доходит до "неправильного" выбора использования глобальных/общих/статических переменных, а также паттерна singleton.
В вашем случае вы говорите конкретно о конфигурации. Я не вижу ничего плохого в использовании шаблона синглтона для доступа к этим элементам конфигурации. У каждого приложения есть конфигурация, она ДОЛЖНА быть в месте, которое можно просто вызвать, нет необходимости просто передавать ее, это больше усложняет, чем помогает.
Главное здесь - убедиться, что вам действительно нужно, чтобы информация существовала только один раз, конфигурация - одна из лучших причин, которые я нашел для использования этого типа паттерна.
Глобальные данные, которые являются неизменными, или четко определенные, общие для всего процесса объекты (например, протоколирование), обычно можно использовать в качестве глобальных данных. Данные конфигурации, особенно если они живут в локальном файле, попадают под ту же категорию (есть только один файл для всего процесса/приложения, аналогично регистрации).
В общем, если вы обнаружите, что вам приходится передавать дополнительные аргументы только для того, чтобы передать их другой функции, вам следует вынести эту функцию "наверх" и завести другую, посредническую. Другим, более практичным подходом, иллюстрирующим это, является разработка на основе тестирования, поскольку она заставляет вас передавать зависимости.
Еще один способ подумать об этом: если функция не может легко узнать все детали для вызова подфункции, подтяните подфункцию вверх и заставьте более высокий, более знающий уровень получить необходимую информацию. Я обнаружил, что эта техника очень способствует качеству кода, поскольку она создает разделенные части, а не монолитных зверей.
В вашем примере с active directory вместо того, чтобы передавать аргументы для ad_connect, передайте объект, который обрабатывает необходимую логику, затем функцию, которая является посредником между этим объектом и функцией, использующей его
def create_user(name, ad_user, ad_pass, ad_ou, ...):
conn = ad_connect(ad_user, ad_pass, ...)
conn.CreateRecord(ad_user)
def create_user_mediator(name, ad_controller):
ad_controller.CreateRecord("cn=%s" % name)
Это всего лишь один из способов сделать это, и, конечно, он имеет свои плюсы и минусы. Это просто пример того, как create_user может избежать необходимости использовать глобальные переменные.