spring - 単一責任原則 (SRP) の違反による Spring アプリの設計上の欠陥の可能性

Question

現在、SOLID の原則、特に SRP について学んでいます。

この原則を理解するために、私は少し前に、アプリケーション全体のすべてのサービス メソッドを含む単一の Spring Service クラスを持つ小さなアプリケーションに取り組んだことを思い出します。

さらに、すべてのjpa-dataアクセスメソッドを含む単一のDAOクラスがありました。

これはすべて、明らかに SRP に違反しています。ではない？

Answer 1

はい、いいえ、ここでの考え方は、「変更の軸」が 1 つしかないクラスは「SRP 承認済み」であるということです (Martin の専門用語が大好きです)。よく言えば、「このクラスを変更する理由は 1 つ以上ありますか?」ということです。IEあなたのサービスクラスが他のサービスを呼び出し、そのサービス呼び出しが返したものに対していくつかのビジネスロジックを実行する集約された（たとえば）ロジックである場合、そのサービスクラスには2つの変更軸があります。もう 1 つは、ビジネス ロジックが変更された場合です。この場合、他のサービスを呼び出す部分と、返された結果にビジネス ロジックを適用する部分を分離する必要があります。

ただし、これらのことは「原則」と呼ばれ、「法則」とは呼ばれません。これは、開発するものに常に盲目的に適用されるべきではなく (気が狂わないように:))、コンテキストが必要な場合にのみ適用されるためです。

たとえば、Martin Fawler 自身は、モデル (Java Bean として) と DAO オブジェクトの分離を、彼がAnemicDomainModelと呼ぶアンチ パターンと見なしています。これに代わる良い方法として、Play Frameworks モデルの実装を参照してください。しかし、Java でデータアクセス層を構築する際に、あなたや他の多くの人々が実際にこの Bean と Dao の分離を行ったことがあると確信しています。コード自体はクリーンで、使いやすく、柔軟でした。