web-dev-qa-db-ja.com

コンストラクタに引数を渡すことは常にDIと見なされますか？

プロジェクトデザインでDIの使用をさらに検討し始めたところ、同じ質問をするようになりました。

「このオブジェクトをそのコンストラクターに渡すと、その新しいオブジェクトには依存関係がありますか？」

たとえば、次の場合：

_class App:

    ROOT_DIR = Path('some_dir')
    SOME_CFG = Path(ROOT_DIR, 'some_cfg.cfg')

    def __init__(self, config: Config) -> None:
        self.config = config

class Config:

    def __init__(self, file: Path) -> None:
        self.file = file
_

Appはすべての構成タスクを担当するため、ConfigはConfigに依存します。

質問し始めるところは、Configがどのように構築されるかです：Config(App.SOME_CFG)。

それで、Configのコンストラクタに何かを渡した場合、依存関係があるということですか？

designobject-oriented-designdependency-injectionconstructors
1
pstatix

このオブジェクトをそのコンストラクターに渡すと、その新しいオブジェクトには依存関係がありますか？

いいえ。合格したからといって、それが使用されるとは限りません。 nullを渡しても問題ない場合があります。

依存関係を持つということは、それに依存しているということです。君はそれが要る。

今では、機械的に、Dependency Injectionはファンシーな名前で参照を渡すだけのことです。しかし、その背後にある考え方は、あなたが依存しているものはあなたに渡されるべきだということです。あなた自身でそれらを構築したり、それらを見つける方法を理解したりすべきではありません。これがDIの「パターン」の基本的な要件です。

これにより、依存関係を隠すことができなくなります。必要なものを明示的に要求する必要があります。これを行うコードは、ニーズを隠さないため、保守がはるかに簡単です。

さて、あなたがそれを変態させて、そしてあなたが必要でないものを求めるならば、まああなたはただジャークであるだけです。

5
candied_orange

文字通り？ はい、ワイヤおよびドープシリコンとともに。

概念的には？ 番号

データ構造とオブジェクト

データ構造は、コードがメモリの領域に課すものです。別のメモリ領域を渡すことができますが、動作の範囲は渡されません。これらはリーダーによって提供されます。

ネイティブデータタイプは、一般的にデータ構造です。タプル、配列、スタックフレーム、オブジェクトストレージ、静的ストレージなどの基本的な構造も含まれます。もちろん例外もあります。

オブジェクトはコードから完全に分離されています。オブジェクトは、コードがそれらと通信できるインターフェースを提供します。そのインターフェイスは通常、スタックフレームと呼ばれる事前に合意されたデータ構造ですが、ネットワーク上のデータグラムなどの他の手法が使用される場合もあります。

この定義により、関数はオブジェクトであり、クラス型のインスタンス、または一般に、インターフェースを実装から実際に分離できるものはすべてインスタンスになります。つまり、データ構造（ボックス化されていない）とオブジェクト（ボックス化された）の両方であるJavaの整数など、一部の基本的な型も一部の言語ではオブジェクトです。

依存性注入

オブジェクトには、多くの場合、共同編集者として他のオブジェクトが必要です。優れたオブジェクトユーザーのように、どの特定のオブジェクトと共同作業するかは気にせず、特定のインターフェイスを提供するだけです。

Dependency Injectionは、コラボレーターを使用してオブジェクトをプロビジョニングする手法です。

質問はこれです：オブジェクトは渡された引数をコピーまたは参照しますか？

  • コピーする場合、引数はデータ構造として扱われます。
  • それが参照する場合、引数はオブジェクトとして扱われます。
1
Kain0_0