The Single Responsibility Principle(単一責任の原則)

gistfile1.txt

# なぜやるか
役割が単一なクラスの仕様が変更になった場合、その変更部分は把握しやすいから。
単一でない場合、１つの箇所を変えた時にどのような挙動が起こるか想定しずらくこれはもろい設計に当てはまる。

# どう分けるか
変更する理由が同じ場合は同じクラス(やモジュールとか)に、理由が異なる場合は違うクラスに分けるべき。

下記の例だとEmployeeクラスに住んでいる3つのメソッドはそれぞれ異なる理由で変更される可能性がある。
calculate_payrollは給与計算の計算式が変更されたら対応して修正しないといけないし、report_hoursはレポートのフォーマットが変更されるたびに修正が必要だ。つまり今のEmployeeクラスは様々な変更される理由を持っていて、そのたびにこのクラスとこのクラスに依存している他のクラスや処理を変更しないといけなくなる。
最適なクラス設計は、calculate_payrollが変更されても、この処理に依存していた他のクラスのインタフェースには変更が入らないことだ。

```
class Employee
  def calculate_payroll
    # 給与計算メソッド
  end
  
  def report_hours
    # 出勤時間のレポート発行
  end
  
  def save
    # do something for DB
  end
end
```

↑の例はこのようにすることで結合度の低くすることができる。

3つのクラスはそれぞれ別のコンポーネントに配置されることになる。レポート関連のクラスと、データベース関連のクラスと、ビジネスルール関連のクラスが、すべて別のコンポーネントに配置されるということ。
EmployReporterとEmployeeRepositoryはEmployeeに依存している。つまりEmployeeが修正されればこの2つのクラスは変更しないとイケない可能性が高いが、それでもEmployReporterとEmployeeRepositoryの2つは独立して変更を加えることができるようになった！

```
class Employee
  def calculatePay
  end
end

class EmployReporter
  def reportHours(employee)
  end
end

class EmployeeRepository
  def save
  end
end
```