Как лучше производить инициализацию «внутренних» объектов? У меня имеется некий класс Application, в котором внутри определен ряд объектов, описывающих непосредственно само приложение: набор роутов + вьюшки для них. Естественно сделать еще поддержку middlewar'ов, чтобы до вызова нужного обработчика для запроса, выполнить ряд действий по предобработке (например, токен проверить/добавить). Для этих middlewar'ов мне нужна инициализация, которая бы, например, брала или пользовательские настройки (если определены), либо дефолтовые, которые я укажу (например хранить где-нибудь в памяти токены, если пользователь не хочет хранить в БД (или не указал)).
Вопрос в том, как решить красиво и элегантно данную задачу? У меня пока пришло в голову:
1) Пробрасывать аргументы пришедшие в Application класс, а от него, внутрь, в глубину (то есть все конструкторы имеют сигнатуру: def __init__(self, *args, **kwargs):
# берем какие-то настройки из аргументов/словаря и делаем нужное
....
что на текущий момент времени сделано, но не сказать что абсолютно меня полностью удолетворяет.
2) Сделать нечто наподобие механизма настроек как в Django (имеются какие-то дефолтовые настройки + пользовательские). Вроде бы и круто, но тогда надо и писать свой скрипт, через который пользователь будет ранить свой скрипт (опять же, как джанге), вместо того, чтобы просто запустить у себя скрипт, в котором есть:if __name__ == '__main__':
cmd = CommandLine()
cmd.define('-ip', default='127.0.0.1', help='used ip', type=str)
cmd.define('-port', default=8080, help='listened port', type=int)
args = cmd.parse_command_line()
app = Application()
app.run(ip=args.ip, port=args.port, router=router)
Подскажите, какой способ реализации оптимальнее/лучше и почему. Быть может есть какие-то еще более интересные варианты?
Как лучше производить инициализацию «внутренних» объектов? У меня имеется некий класс Application, в котором внутри определен ряд объектов, описывающих непосредственно само приложение: набор роутов + вьюшки для них. Естественно сделать еще поддержку middlewar'ов, чтобы до вызова нужного обработчика для запроса, выполнить ряд действий по предобработке (например, токен проверить/добавить). Для этих middlewar'ов мне нужна инициализация, которая бы, например, брала или пользовательские настройки (если определены), либо дефолтовые, которые я укажу (например хранить где-нибудь в памяти токены, если пользователь не хочет хранить в БД (или не указал)).
Вопрос в том, как решить красиво и элегантно данную задачу? У меня пока пришло в голову:
1) Пробрасывать аргументы пришедшие в Application класс, а от него, внутрь, в глубину (то есть все конструкторы имеют сигнатуру: def __init__(self, *args, **kwargs):
# берем какие-то настройки из аргументов/словаря и делаем нужное
....
что на текущий момент времени сделано, но не сказать что абсолютно меня полностью удолетворяет.
2) Сделать нечто наподобие механизма настроек как в Django (имеются какие-то дефолтовые настройки + пользовательские). Вроде бы и круто, но тогда надо и писать свой скрипт, через который пользователь будет ранить свой скрипт (опять же, как джанге), вместо того, чтобы просто запустить у себя скрипт, в котором есть:if __name__ == '__main__':
cmd = CommandLine()
cmd.define('-ip', default='127.0.0.1', help='used ip', type=str)
cmd.define('-port', default=8080, help='listened port', type=int)
args = cmd.parse_command_line()
app = Application()
app.run(ip=args.ip, port=args.port, router=router)
Подскажите, какой способ реализации оптимальнее/лучше и почему. Быть может есть какие-то еще более интересные варианты?
Вопрос в том, как решить красиво и элегантно данную задачу? У меня пока пришло в голову:
1) Пробрасывать аргументы пришедшие в Application класс, а от него, внутрь, в глубину (то есть все конструкторы имеют сигнатуру: def __init__(self, *args, **kwargs):
# берем какие-то настройки из аргументов/словаря и делаем нужное
....
что на текущий момент времени сделано, но не сказать что абсолютно меня полностью удолетворяет.
2) Сделать нечто наподобие механизма настроек как в Django (имеются какие-то дефолтовые настройки + пользовательские). Вроде бы и круто, но тогда надо и писать свой скрипт, через который пользователь будет ранить свой скрипт (опять же, как джанге), вместо того, чтобы просто запустить у себя скрипт, в котором есть:if __name__ == '__main__':
cmd = CommandLine()
cmd.define('-ip', default='127.0.0.1', help='used ip', type=str)
cmd.define('-port', default=8080, help='listened port', type=int)
args = cmd.parse_command_line()
app = Application()
app.run(ip=args.ip, port=args.port, router=router)
Подскажите, какой способ реализации оптимальнее/лучше и почему. Быть может есть какие-то еще более интересные варианты?
Не можешь разобраться в этой теме?
Обратись за помощью к экспертам
Гарантированные бесплатные доработки в течение 1 года
Быстрое выполнение от 2 часов
Проверка работы на плагиат
Поможем написать учебную работу
Оба способа имеют свои плюсы и минусы, и выбор зависит от ваших конкретных потребностей и предпочтений.
1) Пробрасывание аргументов через конструктор может быть простым и удобным способом передачи параметров во внутренние объекты класса. Тем не менее, это может привести к проблемам с управлением большим количеством аргументов и их сложностью при добавлении новых параметров.
2) Механизм настроек в стиле Django может быть более гибким и масштабируемым подходом. Он позволяет установить дефолтные настройки и переопределить их, при необходимости. Однако, это может потребовать дополнительной работы по созданию и управлению конфигурационным файлом или скриптом.
Если вам нужна простота и легкость использования, то первый вариант может быть предпочтительнее. Если же вам важна гибкость и возможность легко изменять настройки, то второй вариант может быть более подходящим.
Также вы можете рассмотреть вариант использования Dependency Injection (внедрение зависимостей) для управления зависимостями и инициализацией объектов в вашем приложении. Этот подход позволяет более явно указать зависимости и предоставить им нужные параметры при создании.
В целом, выбор способа инициализации "внутренних" объектов зависит от вашего стиля программирования, предыдущего опыта, архитектуры вашего приложения и требуемой гибкости в настройках.