CRUD (作成、読み取り、更新、および削除) 操作を行う UserServiceImpl クラスを設計しているとします。私の見解では、作成、読み取り、更新、および削除は、クラスが変更される 4 つの理由です。このクラスは単一責任の原則に違反していますか? 違反する場合はCreateUserServiceImpl、ReadUserServiceImpl、 、
UpdateUserServiceImpl、 のような 4 つのクラスが必要DeleteUserServiceImplです。授業が多いのはやり過ぎじゃない？
作成、読み取り、更新、および削除操作用にそれぞれ 4 つのインターフェースを定義し、サービス クラスが 4 つのインターフェースすべてを実装するとします。現在、実装クラスは 1 つしか持てませんが、それらのインターフェースを分離することで、アプリケーションの残りの部分に関する限り、概念を切り離しました。これは正しい方法ですか、それとも問題がありますか?
それが私がパターンと原則について気に入っていることです - それらは、誰もが同意するのと同じくらいソフトウェア設計に同意しないための一貫した方法です:-)
私の見解は、クラスが存在する複雑さとコンテキストに応じて、クラスを使いやすく理解しやすいものにする方法でクラスを構築することです。実装とコンテキストが単純であれば、単一のクラスで十分です。CRUD操作を管理する責任があるため、SRPに準拠していると言えます。ただし、実装が複雑な場合、または抽象親クラスに配置するのに適した共有コードが多数ある場合は、CRUD 操作ごとに 1 つずつ、おそらく 4 つの別個のクラスがより理にかなっています。それはあなたがそれをどのように見るかについてのすべてです。
パターンと原則は素晴らしいものですが、間違って使用すると、単純な問題がそれらがないのと同じくらい複雑になる可能性があります。
私の見解では、作成、読み取り、更新、および削除は、クラスが変更される 4 つの理由です。
なんで？
Stackクラスを持っている場合、クラスを変更する理由PushとPop理由は?
私はそうは思わない。これらは、人々がスタックで行う 2 つの標準的な操作です。CRUD と同様に、これはデータ ストレージに対する単純で確立されたよく知られた一連の操作です。
現在、基盤となるストレージ テクノロジ自体が、クラスを変更する理由になっています。つまり、CRUD 実装が MS SQL 6.0 データベースの特定のインスタンスでのみ動作するようにハードコーディングされている場合、SRP に違反していることになり、クラスを簡単に再利用または拡張できなくなります。
4 つのインターフェイスに関しては、これは別の SOLID 原則であるISPに近く、ここでの必要性はデータ ストレージの使用パターンによって決まります。たとえば、一部のクラスがデータ ストレージからの読み取りのみを必要とする場合、Read メソッドのみを使用してインターフェイスを抽出し、そのインターフェイスをそのようなメソッドの引数として要求することは完全に理にかなっています。このインターフェイスを分離することで、後で別の実装を作成できます。おそらく、読み取り専用クライアントの場合は、より最適化されたクエリを発行したり、メモリ キャッシュを使用したりできますが、そうでない場合は、このインターフェイスを実装するデフォルトのデータ ストレージのインスタンスを渡すだけで済みます。
サービスが単一のタイプまたはビジネス情報のデータ サービスを担当するまでは、単一責任の原則に違反しません。