交換可能であるはずのクラス内に依存関係があっても大丈夫ですか？

ドメインモデルがあり、それを永続化レイヤーから読み取って保存したいとしましょう-現在のところ、それはjsonファイルの可能性がありますが、将来的にはxmlまたはデータベース（タイプも変更される可能性があります）になる可能性があります）。

永続化レイヤーからドメインモデルを生成するために、たとえばgetAll()とsaveAll()メソッドを含む簡単なインターフェイスの実装を用意しました。別のタイプの永続化に切り替えたい場合は、インターフェースの実装を変更するだけです。ただし、実装内では、完全に異なるソリューションを使用してデータを読み取り、保存するため、他のライブラリの異なるオブジェクトを使用してデータを処理する必要があります。

最初の実装でJsonシリアライザーを使用するとします。次に、そのシリアライザーのインスタンスを私の実装で直接インスタンス化します。これは、そのシリアライザに依存する私の実装に直接つながります。別のシリアライザを与えることはできません。しかし、シリアライザ（またはあらゆる種類の永続化）のユニバーサルインターフェイスがないため、これはいずれにしても不可能です。したがって、別のシリアライザを使用したい場合、私ができる唯一のことは、外部から別のシリアライザを渡すのではなく、完全に新しい実装を記述することです。

この場合、依存関係をハードコードしても大丈夫ですか？またはより良いオプションはありますか？

最近の質問に対する私の回答を参照すると、ここで重要なのは、階段パターンを使用して、永続化レイヤーインターフェイスを永続化レイヤーの実装から分離することです。

次に、Jsonシリアライザーへの依存関係が、Json永続パッケージの実装の詳細になります。アプリケーションの残りの部分は、それについて何も知る必要がなく、別のパッケージにあるインターフェースを介して永続パッケージにアクセスするだけなので、その依存関係の負担を負う必要はありません。

その後、データベース永続性パッケージを追加すると、それらは単にそれらのインターフェースを実装し、そのORM依存関係などは実装の詳細として隠されます。

コードからすべての依存関係を削除することはできません。最終的には何かに依存する必要があります。そうしないと、すべてを実行する1つの巨大な神オブジェクトになってしまいます。

一般的な規則として、各クラスは、それらよりも安定しているオブジェクトに依存する必要があります。また、不安定な関係で依存性注入を使用して、テストを容易にし、柔軟性を高めたいとします。

JSONシリアライザーが変更される可能性はどのくらいありますか？あなたが書いているコードよりも多少安定していますか？

シリアライザを別の実装に2回以上置き換える可能性がある場合は、シリアライザ自体の周りにプロキシまたはラッパーオブジェクトを作成できます。このようにして、シリアライザとのインターフェースを制御でき、外部ライブラリに1か所でのみ依存します。

とは言っても、私はまだJSONシリアライザーを（別のシリアライザーに）置き換える理由を見つけていないので、直接依存することについてあまり心配する必要はありません。シリアライザは、ほとんどの場合、自分のアプリケーションの何よりも安定したインターフェイスを備えています。そこから必要なメソッドは非常に単純で少数なので、実際に変更する理由はありません。

シリアライザ自体の変更については特に心配していないようですが、説明した内容から、まったく異なる永続化システムへの外部要件の変更が心配されています。この場合、永続化層の実装は完全に書き直されます。とにかく、依存性注入やプロキシを使用しても役に立ちません。

永続化レイヤーとドメインモデルの間のインターフェイスが同じままで、ドメインモデルをユニットテストするときにその永続化レイヤーをモックしている限り、JSONライブラリの特定のインターフェイスに依存していても問題はありません。この依存関係はテストするのが簡単で、JSONライブラリ自体が変更されることはほとんどありません。