私はちょうど好奇心が強く、SRPをよりよく理解するためにも、petclinic spring mvcの例には、所有者、ペット、および訪問のメソッドを持つ1つの大きなクリニックinetrafaceがあります。
一方、SRPは、「1つのクラス（ここではClinic / inetrface自体の実装クラス）が定義された1つのタスクを実行する必要があります。したがって、Clinic inetrfaceは3つのインターフェイスに分割されている必要がありますか？またはSPR / petclinicの例が間違っていますか？
SpringSource PetClinic の例を参照していると仮定します。ドキュメントは言う：
PetClinic の高レベルのビジネス/永続化 API は、org.springframework.samples.petclinic.Clinic インターフェースです。PetClinic の各永続化戦略は、Clinic インターフェースの異なる実装です。
また、次のことも言及されています。
PetClinic アプリケーションはすべてデータベース アクセスに関するものであり、アプリケーションにはそれ以外のビジネス ロジックがほとんどないため、主要なビジネス レイヤー API と永続レイヤー API が分離されていません。この設計手法は、より複雑なビジネス ロジックを持つアプリケーションには使用しないでください。ただし、永続性に関連しないすべてのビジネス ルールがビジネス オブジェクトに実装されており、永続化レイヤーに漏れていないため、ここでは許容されます。設計の最も重要な側面は、ビジネス層と永続層がプレゼンテーション層から完全に独立していることです。
最後に、元の定義によれば、SRP は次のように述べています。
クラスには、変更する理由が 1 つだけある必要があります。
Clinic インターフェイスはアプリケーションの永続化 API をカプセル化し、その実装は、使用される永続化戦略/テクノロジの根本的な変更によってのみ変更されるため、ある意味で設計は SRP と一貫性があります。一方、言及されているように、これは非常に単純な例であり、より複雑なアプリケーションでは、永続化/データ アクセス レイヤーがエンティティごとに分割される可能性が高いと推測されます。通常、1 つになることになります。主要エンティティごとの DAO。PetClinic では、OwnerDAO、PetDAO、VisitDAO のようなものです。