PythonでIoC / DIが一般的ではないのはなぜですか？

Javaでは、IoC / DIは非常に一般的な手法であり、Webアプリケーション、ほぼすべての利用可能なフレームワーク、Java EEで広く使用されています。その一方で、大きなPython Webアプリケーションもたくさんありますが、Zope（コードで言うと恐ろしいはずですが）の他に、IoCはPythonの世界ではあまり一般的ではないようです。（私が間違っていると思われる場合は、いくつか例を挙げてください）。

もちろん、Pythonで使用できる一般的なJava IoCフレームワークのクローンがいくつかあります（たとえば、springpython）。しかし、どれも実際に使われているようには見えません。少なくとも、私はそのようなものを使用するDjangoまたはsqlalchemy + <insert your favorite wsgi toolkit here>ベースのWebアプリケーションに踏み込んだことはありません。

私の意見では、IoCには妥当な利点があり、たとえばdjango-default-user-modelを簡単に置き換えることができますが、PythonでのインターフェースクラスとIoCの広範な使用は、「pythonic」ではなく、少し奇妙に見えます。しかし、誰かがより良い説明をしているかもしれません。なぜIoCはPythonで広く使用されていないのでしょうか。

私は実際にDI / IoCのがあるとは思わないという Pythonで珍しいです。何で珍しい、しかし、DI /のIoCあるフレームワーク/コンテナ。

それについて考えてください：DIコンテナーは何をしますか？それはすることができます

1. 独立したコンポーネントを完全なアプリケーションに配線...
2. ...実行時。

「一緒に配線する」と「実行時」の名前があります。

1. スクリプティング
2. 動的

したがって、DIコンテナーは、動的スクリプト言語のインタープリターにすぎません。実際、言い換えると、典型的なJava / .NET DIコンテナーは、お尻が醜く、時にはXMLベースの構文を持つ、非常に悪い動的スクリプト言語のくだらないインタプリタにすぎません。

Pythonでプログラミングするとき、美しくて見事なスクリプト言語を自由に使えるのに、どうして醜くて悪いスクリプト言語を使いたがるのでしょうか。実際、これはより一般的な質問です。ほとんどすべての言語でプログラミングする場合、JythonとIronPythonを自由に使用できるのに、醜い悪いスクリプト言語を使用するのはなぜでしょうか。

つまり、要約すると、DI / IoCの実践は、まったく同じ理由で、Javaと同様にPythonでも同様に重要です。ただし、DI / IoC の実装は言語に組み込まれており、多くの場合非常に軽量なので完全に消えます。

（ここでは、類似点を簡単に説明しておきます。アセンブリでは、サブルーチン呼び出しはかなり重要なことです。ローカル変数とレジスタをメモリに保存し、戻りアドレスをどこかに保存し、命令ポインタを呼び出しているサブルーチンに変更する必要があります。サブルーチンが終了したら、なんとかしてサブルーチンに戻り、引数を呼び出し先が見つけられる場所に置くなどの準備をします。IOW：アセンブリでは、「サブルーチン呼び出し」はデザインパターンであり、以前は次のような言語がありました。サブルーチン呼び出しが組み込まれているFortranは、独自の「サブルーチンフレームワーク」を構築していました。サブルーチンフレームワークを使用しないという理由だけで、Pythonではサブルーチン呼び出しは「一般的ではない」と思いますか？）

ところで：DIを論理的な結論に導くのがどのように見えるかの例については、Gilad BrachaのNewspeakプログラミング言語とその主題に関する彼の著作を見てください。

• 有害と見なされるコンストラクタ
• 致死注射
• 輸入禁止（続き）

その一部は、Pythonでモジュールシステムが機能する方法です。モジュールからインポートするだけで、一種の「シングルトン」を無料で入手できます。モジュール内のオブジェクトの実際のインスタンスを定義すると、すべてのクライアントコードがそれをインポートして、実際に機能し、完全に構築された/生成されたオブジェクトを取得できます。

これは、オブジェクトの実際のインスタンスをインポートしないJavaとは対照的です。これは、常に自分でインスタンス化する必要があることを意味します（または、ある種のIoC / DIスタイルのアプローチを使用します）。静的なファクトリメソッド（または実際のファクトリクラス）を用意することで、すべてを自分でインスタンス化する手間を軽減できますが、それでも実際に毎回新しいメソッドを作成するというリソースオーバーヘッドが発生します。

IoCとDIは成熟したPythonコードでは非常に一般的です。ダックタイピングのおかげで、DIを実装するためのフレームワークは必要ありません。

最良の例は、次を使用してDjangoアプリケーションを設定する方法ですsettings.py。

# settings.py
CACHES = {
    'default': {
        'BACKEND': 'django_redis.cache.RedisCache',
        'LOCATION': REDIS_URL + '/1',
    },
    'local': {
        'BACKEND': 'django.core.cache.backends.locmem.LocMemCache',
        'LOCATION': 'snowflake',
    }
}

Django Rest FrameworkはDIを多用しています：

class FooView(APIView):
    # The "injected" dependencies:
    permission_classes = (IsAuthenticated, )
    throttle_classes = (ScopedRateThrottle, )
    parser_classes = (parsers.FormParser, parsers.JSONParser, parsers.MultiPartParser)
    renderer_classes = (renderers.JSONRenderer,)

    def get(self, request, *args, **kwargs):
        pass

    def post(self, request, *args, **kwargs):
        pass

思い出させてください（ソース）：

「依存性注入」は、5セントのコンセプトを表す25ドルの用語です。[...]依存性注入とは、オブジェクトにインスタンス変数を与えることです。[...]。

Djangoは制御の反転をうまく利用しています。たとえば、データベースサーバーは構成ファイルによって選択され、フレームワークは適切なデータベースラッパーインスタンスをデータベースクライアントに提供します。

違いは、Pythonには一流の型があることです。クラスを含むデータ型は、それ自体がオブジェクトです。特定のクラスを使用したい場合は、クラスに名前を付けます。例えば：

if config_dbms_name == 'postgresql':
    import psycopg
    self.database_interface = psycopg
elif config_dbms_name == 'mysql':
    ...

その後のコードは、次のように記述してデータベースインターフェイスを作成できます。

my_db_connection = self.database_interface()
# Do stuff with database.

JavaとC ++が必要とするボイラープレートファクトリ関数の代わりに、Pythonは1行または2行の通常のコードでそれを行います。これは、関数型プログラミングと命令型プログラミングの長所です。

依存関係の注入と制御の反転が意味することを人々が本当に理解していないことがわかりました。

制御の反転を使用する慣例は、別のクラスまたは関数に依存するクラスまたは関数を持つことですが、関数コードのクラス内でインスタンスを作成する代わりに、パラメーターとして受け取ることをお勧めします。そのため、疎結合をアーカイブできます。テスト可能性が高くなり、リスコフ置換の原理を構築することには、多くの利点があります。

インターフェースとインジェクションを操作することで、コードのメンテナンス性が向上します。これは、動作を簡単に変更できるためです。コードの1行（DI構成では1行か2行）を書き換える必要がないためです。クラスが待機しているインターフェースを実装するクラスは、インターフェースに従う限り独立して変化する可能性があるため、その動作を変更するクラス。コードを分離して維持しやすくするための最良の戦略の1つは、少なくとも単一の責任、置換、依存関係の逆転の原則に従うことです。

パッケージ内で自分でオブジェクトをインスタンス化し、それをインポートして自分でインジェクトでき​​る場合に役立つDIライブラリは何ですか？選択された答えは正しいです。Javaには手続き型セクション（クラス外のコード）がないため、すべてが退屈な構成xmlに含まれるため、遅延ロード方式で依存関係をインスタンス化して注入するクラスが必要になるため、吹き飛ばされませんあなたのパフォーマンス、Pythonではコードの「手続き型」（クラス外のコード）セクションにインジェクションをコーディングするだけ

数年前にPythonを使用していませんが、動的型付け言語であることは、何よりも関係があると思います。簡単な例として、Javaで何かが適切に標準出力に書き込まれたことをテストしたい場合は、DIを使用して任意のPrintStreamに渡し、書き込まれているテキストをキャプチャして検証できます。ただし、Rubyで作業しているときは、STDOUTの「puts」メソッドを動的に置き換えて検証を行うことができるため、DIを完全に除外できます。抽象化を作成している唯一の理由がそれを使用しているクラスをテストすることである場合（ファイルシステム操作またはJavaのクロックを考える）、DI / IoCはソリ​​ューションに不要な複雑さを作成します。

実際、DIを使用して十分にクリーンでコンパクトなコードを書くのは非常に簡単です（おそらく、Pythonicであり続けるでしょうが、とにかく:)）、たとえば、私は実際にこのコーディング方法を好みます。

def polite(name_str):
    return "dear " + name_str

def rude(name_str):
    return name_str + ", you, moron"

def greet(name_str, call=polite):
    print "Hello, " + call(name_str) + "!"

_

>>greet("Peter")
Hello, dear Peter!
>>greet("Jack", rude)
Hello, Jack, you, moron!

はい、これは関数/クラスをパラメーター化する単純な形式と見なすことができますが、機能します。したがって、Pythonのデフォルトに含まれているバッテリーで十分かもしれません。

PS私はまた、Pythonでの単純なブール論理の動的評価で、この素朴なアプローチのより大きな例を投稿しました。

IoC / DIはデザインコンセプトですが、残念ながら特定の言語（またはタイピングシステム）に適用されるコンセプトと見なされることがよくあります。依存関係注入コンテナがPythonではるかに一般的になるのを見たいです。Springがありますが、これはスーパーフレームワークであり、「Pythonの方法」をあまり考慮せずにJavaの概念を直接移植したもののようです。

Python 3のアノテーションを考慮して、フル機能を備えたシンプルな依存関係注入コンテナーであるhttps://github.com/zsims/dicに亀裂を入れることにしました。これは.NET依存関係注入コンテナの概念（その領域でプレイしている場合はIMOは素晴らしい）に基づいていますが、Pythonの概念で変更されています。

Pythonの動的な性質により、人々は別の動的なフレームワークの必要性をしばしば目にすることはないと思います。クラスが新しいスタイルの「オブジェクト」を継承する場合、新しい変数を動的に作成できます（https://wiki.python.org/moin/NewClassVsClassicClass）。

つまり 、プレーンpythonの場合：

#application.py
class Application(object):
    def __init__(self):
        pass

#main.py
Application.postgres_connection = PostgresConnection()

#other.py
postgres_connection = Application.postgres_connection
db_data = postgres_connection.fetchone()

しかし、https：//github.com/noodleflake/pyiocを見て、これがあなたが探しているものかもしれません。

つまり、pyioc

from libs.service_locator import ServiceLocator

#main.py
ServiceLocator.register(PostgresConnection)

#other.py
postgres_connection = ServiceLocator.resolve(PostgresConnection)
db_data = postgres_connection.fetchone()

私は "JörgW Mittag"の答えを返します： "DI / IoCのPython実装は非常に軽量なので完全に消えます"。

このステートメントをバックアップするには、JavaからPythonに移植された有名なMartin Fowlerの例を見てください。Python：Design_Patterns：Inversion_of_Control

上記のリンクからわかるように、Pythonの「コンテナ」は8行のコードで記述できます。

class Container:
    def __init__(self, system_data):
        for component_name, component_class, component_args in system_data:
            if type(component_class) == types.ClassType:
                args = [self.__dict__[arg] for arg in component_args]
                self.__dict__[component_name] = component_class(*args)
            else:
                self.__dict__[component_name] = component_class

私の2セントは、ほとんどのPythonアプリケーションではそれを必要としないことであり、たとえそれが必要な場合でも、多くのJava嫌い者（および開発者であると信じる無能なフィドラー）は、それがJavaで人気があるという理由だけで、それを何か悪いものと見なす可能性があります。

IoCシステムは、オブジェクトの複雑なネットワークがあり、各オブジェクトが他のいくつかのオブジェクトへの依存関係であり、それ自体が他のオブジェクトへの依存関係である場合に、実際に役立ちます。そのような場合、これらのオブジェクトをすべて一度定義し、できるだけ多くの暗黙のルールに基づいてそれらを自動的にまとめるメカニズムを用意する必要があります。また、アプリケーションのユーザー/管理者が簡単な方法で構成を定義する必要がある場合は、IoCシステムが単純なXMLファイルのようなもの（構成となる）からコンポーネントを読み取ることができるようにする必要があります。

典型的なPythonアプリケーションははるかに単純で、スクリプトの束であり、そのような複雑なアーキテクチャはありません。個人的に私はIoCが実際に何であるかを知っており（ここで特定の回答を書いた人とは対照的）、限られたPythonの経験でその必要性を感じたことはありません（また、どこでもSpringを使用していません。開発オーバーヘッドを正当化しないでください）。

そうは言っても、IoCアプローチが実際に役立つPythonの状況があり、実際、Djangoがそれを使用していることをここで読みました。

上記と同じ理由がJavaのアスペクト指向プログラミングにも当てはまる可能性がありますが、AOPが本当に価値のあるケースの数はさらに制限されます。

pytestフィクスチャはすべてDI（ソース）に基づいています

PythonでDI / IoCが可能で、簡単で、さらに美しいという点で、@ Jorgに同意します。不足しているのはそれをサポートするフレームワークですが、いくつかの例外があります。私の頭に浮かぶいくつかの例を指摘すると：

• Djangoコメントを使用すると、独自のCommentクラスをカスタムロジックおよびフォームに関連付けることができます。[より詳しい情報]

• Djangoでは、カスタムプロファイルオブジェクトを使用してユーザーモデルにアタッチできます。これは完全にIoCではありませんが、良いアプローチです。個人的には、コメントフレームワークと同じように、ホールユーザーモデルを置き換えたいと思います。[より詳しい情報]

私の意見では、依存性注入のようなものは、厳格で複雑なフレームワークの症状です。コードの本体が非常に重くなり、簡単に変更できない場合は、コードの小さな部分を選択し、それらのインターフェースを定義し、それらのインターフェースにプラグインするオブジェクトを介して動作を変更できるようにする必要があります。それで十分ですが、そもそもそのような複雑さを回避することをお勧めします。

これは、静的型付け言語の症状でもあります。抽象化を表現するために必要な唯一のツールが継承である場合、それはどこでも使用するものです。そうは言っても、C ++は非常に似ていますが、Java開発者が行ったあらゆる場所でビルダーとインターフェースの魅力を取り上げたことはありません。あまりにも多くの一般的なコードを書いてコストを犠牲にして柔軟性と拡張性を実現するという夢があれば、本当のメリットはほとんどなく、あふれ出すことは簡単です。です。文化的なものだと思います。

通常、Pythonの人々は、ジョブを実行するための適切なツールを選択することに慣れていると思います。これは、何でもできる1つの真のツール（千の可能なプラグインを使用）ではなく、考えられる一連の可能な構成の組み合わせを提供するものではありません。 。必要に応じて互換性のある部分はまだありますが、ダックタイピングの柔軟性と言語の比較的単純さにより、固定インターフェースを定義する大きな形式は必要ありません。

Javaの強い型付けの性質とは異なります。Pythonのダックタイピング動作により、オブジェクトの受け渡しが非常に簡単になります。

Java開発者は、物事を柔軟に保ちながら、クラス構造とオブジェクト間の関係の構築に注力しています。IoCはこれを達成するために非常に重要です。

Python開発者は、作業を完了することに集中しています。必要なときにクラスを接続するだけです。クラスのタイプを気にする必要さえありません。ガクガクできる限り、それはアヒルです！この性質のため、IoCの余地はありません。