В Python есть контейнер для инъекций зависимости?

не имеет понятной концепции программирования на основе интерфейса (как в интерфейсах C #),

Просто потому, что компилятор не может проверить, правильно ли вы используете интерфейс, не означает, что «нет понятной концепции интерфейсов». Вы документируете интерфейс и записываете модульные тесты.

Что касается глобальных переменных, это не похоже на public static методы и поля на классах C # или Java, которые действительно различны. Рассмотрим, например, как работает java.lang.Math. Теперь рассмотрим тот факт, что java.lang.Math не является Singleton. Они сделали это по уважительной причине.

При всех этих позитивах действительно есть какая-то точка для контейнера для инъекций зависимости

Я сомневаюсь в этом, но тогда я никогда не видел их в C # или Java. На мой взгляд, инъекция зависимости – это метод программирования. И это действительно не так уж и важно.

Я всегда подозревал, что инъекция зависимостей в качестве шаблона дизайна была плохим запахом, который был создан всем, должен быть классом «нацистское мышление»,

Нет, это не так. Зависимость инъекции является хорошей идеей много времени. Вам не нужен класс, чтобы вставлять зависимости в. Каждый раз, когда вы передаете что-то в свободную функцию в качестве параметра, вместо того, чтобы функция вызывала другую функцию для получения информации, вы в основном делаете то же самое: инверсия элемента управления. Python также позволяет обрабатывать модули аналогично классам во многих отношениях (конечно, больше способов, чем Java и C #). Есть проблемы, которые могут быть решены путем передачи модулей в качестве параметров функций. 🙂

До сих пор я думаю, что могу охватывать фабрики, объекты Singletons, Multi-instance, просто используя Globals.

Синглтоны – плохой запах. Почти во всех случаях, по моему обширному опыту, они существуют, потому что кто-то считал, что было бы плохо (TM) по принципу иметь глобальный, не продумывая возможные варианты, или почему они хотели такого доступа к одному общему объекту , или даже о том, почему глобальные «Плохие» (TM) по принципу «в первую очередь».

Вы можете сделать глобальную функцию на Python, которая действует как фабрика. Тем не менее, я бы сказал, что более Pythonic делает следующее:

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

б) Если __init__ не отрежет его, попробуйте использовать __new__ для управления поведением.

В Python классы – это сами объекты, которые являются вызываемыми. По умолчанию вызов их создает экземпляр класса. С __new__ вы можете подключиться к этому.

c) Используйте декоратор, применяемый к классу. Вот пример, который делает Singleton (только потому):

 def _singleton(cls): instance = cls() result = lambda: instance result.__doc__ = cls.__doc__ return result @_singleton class example(object): pass 

Как это работает: когда вы украшаете класс, _singleton() , когда передается класс. Экземпляр _singleton() и кэшируется, а _singleton() возвращает анонимную функцию, которая возвращает экземпляр при вызове. Для завершения шарады документация класса прикрепляется к анонимной функции. Затем Python перенаправляет имя класса в глобальной области на возвращаемую анонимную функцию. Поэтому, когда вы называете это, каждый раз вы получаете один и тот же экземпляр класса.

Конечно, это все равно можно обойти, конечно (вы можете сделать что-то вроде example().__class__() чтобы получить другой экземпляр), но гораздо более ясно, что вы делаете что-то неправильно, чем если бы вы просто проигнорировали заводскую функцию чтобы нормально использовать конструктор. Кроме того, это означает, что вызывающий код фактически действует так, как если бы он вызывал конструктор нормально 🙂

Duck Typing – это то, что меня сейчас привлекает, поэтому он используется для определения интерфейсов, а затем основывает классы на этих интерфейсах и позволяет статическим материалам покрывать мою глупость, что я чувствую, что без статической типизации контейнеры немного бесполезны.

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

Вывод

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

Включение зависимостей все еще используется. Всегда будет необходимо, чтобы объекты связывались с уже созданными объектами. Будет необходимо, чтобы «родительские» объекты (или контейнеры или что-то еще) устанавливали состояние своих «детей». Они должны быть переданы через некоторый метод или заданы через какое-то назначение, но в абстрактном смысле это одно и то же.

Оригинальный ответ:

Типовые системы

Python во многих отношениях является вторым наиболее математически чистым языком, с которым я когда-либо сталкивался, – он следует только схеме (хотя я никогда не использовал Haskell, я понимаю, что тоже там).

Python поддерживает замыкания изначально, он имеет продолжения (синтаксис вывода), множественное наследование и синтаксис понимания цикла, который в значительной степени не имеет аналогов. Все это приближает его к оригинальному видению Церкви Алонсо в Lambda Calculus (оригинальные идеи Маккарти за Lisp). Python 3 делает его еще более чистым с множеством понятий (которые заставляют мое сердце трепетать, думая о своей неотъемлемой красоте).

Постоянно и постоянно существует идея, что данные, хранящиеся в переменных Python, имеют больше общего с их аналогами в математике, настолько, что интерфейс объекта может быть уменьшен просто, «прилагательные или множество прилагательных, которые описывают объект". В принципе, интерфейс объекта полностью и полностью содержится в его __dict__ и отображается с помощью dir .

Все это считало, что начинает задумываться, действительно ли «традиционный» способ взглянуть на вещи («традиционный» с кавычками, поскольку Python так же стара, как Java) действительно может работать на таком языке. Когда даже списки аргументов в Python имеют чувство ООП к ним (kwargs, кто-нибудь?), Он действительно превращает мир в обратную сторону.

Включение зависимостей все еще используется. Всегда будет необходимо, чтобы объекты связывались с уже созданными объектами. Будет необходимо, чтобы «родительские» объекты (или контейнеры или что-то еще) устанавливали состояние своих «детей». Они должны быть переданы через некоторый метод или заданы через какое-то назначение, но в абстрактном смысле это одно и то же. Но есть неявное доверие, что содержимое объекта __dict__ переданного объекта будет содержать соответствующее описание. Из-за этого он становится намного меньше: «Как только я создам этот объект, я дам ему все, что нужно для жизни» и намного больше: «Ну, да, объекту нужно состояние, поэтому я давая ему один ».

И это раскрывает скрытый аспект статической типизации. Для того, что ожидает IFoo , он должен иметь полное и полное знание того, что значит быть IFoo , даже если ему никогда не понадобится 90% этого определения. Между тем, утиная печать делает зависящий объект только знать, что свойства X, Y и Z должны быть там во время выполнения.

Глобалы

Что касается глобалов. Избегайте их, если у вас нет другого выбора. Вам лучше использовать Singleton, если только потому, что Singletons позволяют вам регистрироваться при изменении значения. Это не относится к глобалам.

Существует правило программирования, более открытый и сложный интерфейс, тем сложнее его поддерживать. Если что-то помещено в глобальную переменную, что-либо в этом модуле и, возможно, что-либо в ЛЮБОЙ модуль может изменить значение. Код может почти стать недетерминированным. Уверяю вас, печаль идет.