Почему IoC / DI не распространены в Python?

Question

В Java IoC / DI - это очень распространенная практика, широко используемая в веб-приложениях, почти во всех доступных средах и Java EE. С другой стороны, есть также много больших веб-приложений на Python, но кроме Zope (который, как я слышал, должно быть ужасно кодировать), IoC, похоже, не очень распространен в мире Python. (Пожалуйста, назовите несколько примеров, если вы считаете, что я не прав).

Существует, конечно, несколько клонов популярных фреймворков Java IoC, доступных для Python, например, springpython . Но, похоже, практически никто из них не привык. По крайней мере, я никогда не сталкивался с веб-приложением на основе Django или sqlalchemy + <insert your favorite wsgi toolkit here>, которое использует что-то подобное.

По моему мнению, IoC имеет разумные преимущества и позволит легко заменить, например, django-default-user-model, но широкое использование классов интерфейса и IoC в Python выглядит немного странным, а не «pythonic». Но, возможно, у кого-то есть лучшее объяснение, почему IoC не широко используется в Python.

Answer 1

Мой 2cents заключается в том, что в большинстве приложений Python он вам не нужен, и даже если вам это нужно, есть вероятность, что многие ненавистники Java (и некомпетентные фиддлеры, которые считают себя разработчиками) считают это чем-то плохим, просто потому, что это популярный в Java.

Система IoC действительно полезна, когда у вас есть сложные сети объектов, где каждый объект может зависеть от нескольких других и, в свою очередь, сам по себе зависеть от других объектов. В таком случае вы захотите определить все эти объекты один раз и иметь механизм для их автоматического объединения, основанный на максимально возможном количестве неявных правил. Если у вас также есть конфигурация, которая должна быть определена простым способом пользователем / администратором приложения, это еще одна причина, по которой вам нужна система IoC, которая может считывать свои компоненты из чего-то вроде простого XML-файла (который будет конфигурацией).

Типичное приложение Python намного проще, просто набор скриптов, без такой сложной архитектуры. Лично я знаю, что такое IoC (в отличие от тех, кто написал определенные ответы здесь), и я никогда не чувствовал необходимости в этом из-за моего ограниченного опыта работы с Python (также я не использую Spring везде, не когда преимущества это не оправдывает затрат на разработку).

Тем не менее, существуют ситуации Python, где подход IoC действительно полезен, и, на самом деле, я читал здесь, что Django использует его.

Те же рассуждения, приведенные выше, могут быть применены к аспектно-ориентированному программированию в мире Java, с той разницей, что число случаев, когда AOP действительно стоит, еще более ограничено.

Answer 2

В отличие от строго типизированной природы в Java. Поведение Python по типу "утка" позволяет легко передавать объекты.

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

Разработчики Python сосредоточены на выполнении работы. Они просто подключают занятия, когда им это нужно. Им даже не нужно беспокоиться о типе класса. Пока это может крякать, это утка! Эта природа не оставляет места для IoC.

Answer 3

Я согласен с @Jorg в том смысле, что DI / IoC возможен, проще и еще красивее в Python. Чего не хватает, так это фреймворков, поддерживающих его, но есть несколько исключений. Вот несколько примеров, которые приходят мне в голову:

• Комментарии Django позволяют вам связать свой собственный класс Comment с вашей собственной логикой и формами. [Подробнее]

• Django позволяет использовать пользовательский объект профиля для присоединения к вашей модели пользователя. Это не совсем IoC, но это хороший подход. Лично я хотел бы заменить дырочную пользовательскую модель, как это делает каркас комментариев. [Подробнее]

Answer 4

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

Это также признак статически типизированного языка. Когда единственным средством выражения абстракции является наследование, это то, что вы используете везде. Сказав это, C ++ очень похож, но никогда не привлекал внимание к Builders и Interfaces везде, как это делали разработчики Java. Легко преувеличить себя с мечтой быть гибким и расширяемым за счет написания слишком большого количества универсального кода с небольшой реальной пользой . Я думаю, что это культурная вещь.

Как правило, я думаю, что Python люди привыкли выбирать правильный инструмент для работы, который представляет собой единое и простое целое, а не One True Tool (с тысячей возможных плагинов), который может делать что угодно, но предлагает изумительный массив возможные перестановки конфигурации. Там все еще есть взаимозаменяемые части, где это необходимо, но без необходимости большого формализма определения фиксированных интерфейсов, из-за гибкости утки и относительной простоты языка.