SRP プリンシパルは次のように述べています。
クラスまたはモジュールには、変更する理由が 1 つだけある必要があります
Facadeサービス層クラスとしていくつかのクラスがあります。たとえば、いくつかのSaleServiceメソッドを提供すること。たとえば、、、、、...SaveOrder()CancelOrder()CreateOrder()GetAllOrders()GetAllPlannedOrders()
それらの概念的な関係のために、私はそれらをまとめただけです。
change() する理由が複数ある可能性があるこのメソッドでそのようなクラスを使用すると、SRP に違反しますか? はいの場合、どうすればこの問題を処理できますか?
SRP の目的は、クラスがやりすぎているケースを特定することだと思います。複数のクラスを使用することで、より良い設計が可能になります。古典的な例: ReportProducer クラスは、データを組み立てるための作業と出力をフォーマットするための作業を行います。おそらく 2 つのクラスが必要です。1 つは収集用、もう 1 つはフォーマット用です。このアプローチの利点の 1 つは柔軟性です。1 つの収集クラスと複数の異なるフォーマッタ クラスを使用できます。
あなたの例は非常に合理的であるように見えます。一貫したクラスがあり、すべてのメソッドが関連しており、クラスのユーザーは、これが注文のために行くクラスであることを知っています。これは私には単一の責任のように見えます。
変更の理由は何ですか？レポートの例では、まったく異なる 2 種類の変更があります。データの取得元が変更されるか、目的の形式が変更されるかです。あなたの例では、複数の理由が考えられると主張することができます: Order の「形状」が変更される可能性があり、目的のインターフェイスが変更される可能性があります (たとえば、queryCancelledOrders() メソッドを追加する) ファサードであるバックエンド変わるかもしれません。ただし、これらが SRP に違反しているとは思えません。これらはすべて、注文を操作するためのインターフェイスを提示するタスクに関連しています。
「単一の変更理由」を完全に文字どおりに解釈するとしたら、クラスを作成できるとは思えません。常にインターフェースと実装があり、通常はいくつかの依存クラスもあります。それらのいずれかが変更される可能性があるため、常に少なくとも 2 つ、おそらく 3 つの変更の理由があります。
代わりに、「このクラスの責任は何ですか?」と考えてください。「AND」などの言葉を使わずに文章で表現できますか。悪い: データを収集し、レポートをフォーマットします。