Android SQLite データベースを扱う際に、これらの両方のアプローチを推奨している人を見かけます。個人的には Singleton データベース ロック パターンを好みますが、新しい開発手法では Singleton パターンを除外するよう提案されています。
そして今、私は慣れ親しんだものを使い続けるか、「新しくてより良い」ものを使い始めるかで混乱しています.
将来性のあるアプローチはどれですか? シングルトンのアプローチは、将来放棄されるほど悪いのでしょうか?
Android SQLite データベースを扱う際に、これらの両方のアプローチを推奨している人を見かけます。個人的には Singleton データベース ロック パターンを好みますが、新しい開発手法では Singleton パターンを除外するよう提案されています。
そして今、私は慣れ親しんだものを使い続けるか、「新しくてより良い」ものを使い始めるかで混乱しています.
将来性のあるアプローチはどれですか? シングルトンのアプローチは、将来放棄されるほど悪いのでしょうか?
優れた SOLID コーディング プラクティスの一環として、シングルトンは一般的に推奨されません。シングルトンは、コードのどこからでも、依存関係をプルダウンしてどこからでもアクセスできるという点で、ちょっとした魔法のようになります。
これにより、コードベースに高レベルの結合が作成され、変更が難しくなり、テストが非常に難しくなります。
一方、ContentProvider のようなパターンは、インターフェイスと抽象化へのコーディングを促進します。これを慎重に使用すると結合が減り、プロバイダー インスタンスをより簡単に置き換えることができます。これは、コードの柔軟性とコードのテスト容易性の両方に優れています。
もちろん、これはシングルトンの場所がまったくないということではありません。確かに、シングルトンを使用しないことが意味をなさない状況もありますが、回避できる場合は回避するのが最善です。
「将来性」が「より柔軟で変更しやすい」ことを意味する場合は、ContentProvider パターンを使用することをお勧めします。