2
チームに単一責任原則を提示してプロジェクトで使用するセミナーを開催しました。私は、次の一般的な例を使用 ：単体責任原則を使用する代わりに、クラスに新しいメソッドを追加する必要があります
class Employee:
save()
calculate_salary()
generate_report()
をそして私はすべてが、このクラスで大丈夫であるかどうかを伝えるためにチームを尋ねました。誰もそれは大丈夫だと私に言った。 しかし、私はここでSRP原則の3つの違反を見る。 私はクラスからすべてのメソッドを抽出する必要があると言えばいいですか？ 私の推論：
save（）メソッドは、私たちのデータベースを変更した場合に変更の理由です。
給与ポリシーが変更される可能性があるため、calculate_salary（）メソッドが変更の理由です。
レポートのプレゼンテーション（htmlの代わりにcsv）を変更する場合は、generate_report（）メソッドを変更する必要があります。
最後の方法を考えてみましょう。私は次のHtmlReportGeneratorクラスを思いついた。
class HTMLReportGenerator:
def __init__(self, reportable):
self.reportable = reportable
def generate_csv_report()
class CSVReportGenerator:
def __init__(self, reportable):
self.reportable = reportable
def generate_html_report()
このジェネレータのビジネスロジックが変更されても、Employeeクラスには触れず、これが私の主なポイントでした。さらに、これらのクラスをEmployeeクラスオブジェクト以外のオブジェクトに再利用できるようになりました。チームは別のクラスを思い付いた
しかし：
class Employee:
save()
calculate_salary()
generate_html_report()
generate_csv_report()
彼らはSRPに違反していることを理解し、それが彼らのために大丈夫です。
そして、私が）のために戦うためには他のアイデアを持っていた場所です）
状況上の任意のアイデアは？
"彼らは彼らがSRPに違反していることを理解しています"。彼らがこれを理解しているとはほとんど信じられない。 SRPは終わりの手段です。この目的は保守性です。このような小さなサンプルを孤立して見ると、クラスを分割するメリットが見えにくいことがよくあります。 – Steven
はい。システムが成長すると問題が生じることは明らかです。しかし、彼らは、あらゆる種類のレポートに新しいクラスを作成することは大変だと考えています。毎回新しいメソッドを追加するほうが簡単です。 –
この質問はおそらくSOではなくプログラマに属している可能性があります。 – plalx