依存性逆転の原則に 100% 準拠するプログラムを作成できないことはわかっています。私たちは皆、プログラムのインスタンス化文字列によって、何も考えずに違反しています。String はデータ型ではなくクラスであるため、常に具象クラスに依存します。
これに対する解決策があるかどうか疑問に思っていました(純粋に理論的に言えば)。String は「リーク」がほとんどないブラックボックスであり、複雑なバックグラウンド アルゴリズムを備えているため、もちろん実際の実装は期待できません :)
依存性逆転の原則に 100% 準拠するプログラムを作成できないことはわかっています。私たちは皆、プログラムのインスタンス化文字列によって、何も考えずに違反しています。String はデータ型ではなくクラスであるため、常に具象クラスに依存します。
これに対する解決策があるかどうか疑問に思っていました(純粋に理論的に言えば)。String は「リーク」がほとんどないブラックボックスであり、複雑なバックグラウンド アルゴリズムを備えているため、もちろん実際の実装は期待できません :)
この原則の意図は、クラス内でのインスタンスの作成を避けることでも、「new」キーワードの使用を避けることでもありません。したがって、オブジェクト (または文字列) のインスタンス化は原則に違反しません。
また、この原則は、より高いレベルの抽象化 (インターフェースや基本クラスなど) を常に作成して、それを注入し、より疎結合を促進するということでもありません。抽象化がすでに合理的である場合、それを改善しようとする理由はありません。文字列の実装を交換することで得られるメリットは何ですか?
私は実際に数年前にこの質問を投稿しました (準関連): IOC/DI: Is Registering a Concrete Type a Code Smell?
では、原則とは何ですか?それは、自身の責任に重点を置いたコンポーネントを作成し、独自の責任に重点を置いたコンポーネントを注入することです。これらのコンポーネントは通常、依存性注入フレームワークとコンストラクター注入を使用する場合はサービスですが、他のタイプの注入 (メソッド注入など) を行う場合はデータ型にすることもできます。
これらのサービスまたはデータ型がインターフェイスまたは基本クラスである必要はないことに注意してください。原則に違反することなく、絶対に具体的な型にすることができます。