単一責任の原則（S）

導入

Single Responsibility Principle——「1つのクラスは1つの責任だけを持つ」。あれもこれも詰め込んだクラスは、変更のたびに壊れやすくなります。責任を分けると、変更の影響が閉じ込められます。

図解

flowchart TB
    subgraph Before["変更に弱い"]
        G["Report<br/>集計＋整形＋保存＋送信<br/>（何でも屋）"]
    end
    subgraph After["変更に強い"]
        A1["Calculator（集計）"]
        A2["Formatter（整形）"]
        A3["Saver（保存）"]
    end
    Before -->|責任で分割| After

サンプル

// ✅ 責任を分離: 「集計」と「表示」を別クラスに
var calc = new SalesCalculator();
int total = calc.Total(new[] { 100, 200, 300 });

var reporter = new SalesReporter();
reporter.Print(total);   // 売上合計: 600円

class SalesCalculator   // 責任: 計算だけ
{
    public int Total(int[] sales) => sales.Sum();
}

class SalesReporter     // 責任: 表示だけ
{
    public void Print(int total) => Console.WriteLine($"売上合計: {total}円");
}

• 1クラス＝1責任にすると、「計算方法の変更」が表示に波及しない
• 「このクラスを変える理由は1つだけか？」が判断の目安
• 責任が混ざると、片方の変更が他方を壊しやすくなる

演習

var validator = new PasswordValidator();
Console.WriteLine(validator.IsValid("abcdefgh"));   // True
Console.WriteLine(validator.IsValid("abc"));        // False

// TODO: 「8文字以上かどうか」だけを判定する責任を持つ PasswordValidator を定義してください
//       （IsValid(string) → bool）
___

• 期待される出力: True False（2行）

まとめ

• 単一責任の原則：1クラスは1つの責任だけ
• 「変える理由が1つか」を基準に分割する
• 責任分離で変更の影響を局所化できる

次回: 拡張に開き、修正に閉じる「開放閉鎖の原則」です。