クラスのフィールドへ適切に設定させるというものだ。依存関係は図2のようになる。ServiceLocatorもDIも関係ない領域です。GeolocationServiceからIGeolocationServiceインターフェースを抽出して利用箇所の結合度を下げます。.netこれぐらいDIコンテナを自分で作ったことがあればわかると思うんだけどな。誰か有名でそれなりの規模のものを知ってると嬉しいんだが、まあ適当に見つけてきたhttps://github.com/geoserver/geoserver/blob/master/src/main/src/main/java/applicationContext.xmlDIコンテナを使わない場合でも、これ相当のことをコードで書く必要がある。クラスのフィールドへ適切に設定させるというものだ。すべてを保持する、単一のオブジェクトを用意するというものだ。返すメソッドを持つことになる。参照が発生してしまい、結果として図3のような依存関係を示すことになる。.netデザインパターンは、プログラマの間で正確に意味を伝わるようにした共通の用語なんだから当然。それに対してファクトリーはデザインパターンではなく正確な用語じゃないだから意味が正確に伝わらない。同一のものとか言い出しかねないからな。内部で以下相当のことをやることが可能になる内部っていうのは、DIContainer.create関数内部って話ね。何かの入れ物っていうアバウトな定義でいいのであれば、その通りだが。言うなら「ファクトリー+コンテナ」には、インターフェースの実装を生成するオブジェクトのクラスフィールドに設定させるという基本的な考えを実現する機能が抜けてるので「ファクトリー+コンテナ+依存関係の解決」がDIコンテナと言える。.net物理法則と矛盾した世界を定義することも出来るのが数学だからドカタが無能でない世界も定義できる。クラスのフィールドへ適切に設定させるというものだ。すべてを保持する、単一のオブジェクトを用意するというものだ。返すメソッドを持つことになる。参照が発生してしまい、結果として図3のような依存関係を示すことになる。何かの入れ物っていうアバウトな定義でいいのであれば、その通りだが。言うなら「ファクトリー+コンテナ」には、インターフェースの実装を生成するオブジェクトのクラスフィールドに設定させるという基本的な考えを実現する機能が抜けてるので「ファクトリー+コンテナ+依存関係の解決」がDIコンテナと言える。本も雑誌もネットもオープン系SEの話ばかり。構築、保守などをやってきました。web関係の何でも屋です。当方1年目の新人です。”デスマ”と言うのを最近知りました。Reserved.ページTOPへ。