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