Skip to main content
KISS C#版YAGNI C#版SoC C#版ADR C#版HC/LC C#版DRY C#版Refactoring C#版テスト容易な設計 C#版TDD C#版エラーモデリング C#版レイヤー C#版MVC C#版依存関係ルール C#版DIP C#版DI C#版Is-a/Has-a C#版SOLID C#版GoF C#版Observer C#版CQS C#版状態機械 C#版不変条件 C#版Entity/VO C#版DDD C#版集約と境界 C#版ドメインイベント C#版モジュラーモノリス C#版ヘキサゴナル C#版クリーンアーキ C#版ACL C#版API Contract CSSemVer C#版DbC C#版冪等性 C#版CAPの肌感覚 C#版Outbox C#版Saga C#版CQRS C#版ES C#版境界づけられたコンテキスト C#版

第16章：不変条件とは？クラスの健康診断ルール🏥🧱

16.0 この章でわかること🎯✨​

  • **不変条件（Invariant）**って何？を、ふわっとじゃなくスッと理解する😊
  • 「Pre（入口の約束）」「Post（出口の保証）」と何が違うの？を整理する🧠✅
  • C#で「壊れないクラス」を作るための、超実用パターンが身につく🛠️💗

16.1 まず結論：不変条件＝「そのクラスが健康でいるための最低条件」🏥🌿​

不変条件（Invariant）：クラスの健康状態を常に監視するモニター

不変条件（Invariant）は一言でいうと、「そのクラスが生きている間、ずーっと守り抜くべきルール」 だよ🛡️✨

不変条件（Invariant）は、ざっくり言うと👇

  • クラスのインスタンスが「ちゃんとした状態（＝健康）」であるために
  • いつ見ても成立していてほしいルール📏✅

たとえば、銀行口座クラスなら：

  • 残高は 0以上 💰✅
  • 通貨は 必ず設定されている 💴✅

この2つが守れていない口座は…もう口座として壊れてるよね😵‍💫💥

16.2 Pre / Post / Inv の違い（ここで迷子になりがち）🗺️🐣​

Pre（事前条件）☎️🚪​

  • メソッドを呼ぶ側が守る約束
  • 例：Deposit(amount) の amount > 0

Post（事後条件）🎁🚪​

  • メソッドが終わったときに、呼ばれた側が保証すること
  • 例：Deposit(amount) 後は「残高が amount 分増えている」

Inv（不変条件）🧱🏥​

  • **そのクラスの“存在ルール”**みたいなもの
  • 例：いつでも「残高 >= 0」が成り立つ

イメージはこれ👇✨

  • Pre/Post は「メソッドの契約」
  • Inv は「クラスの憲法」📜🧱

16.3 不変条件が弱いと起きる事故😵‍💫💥（あるある）​

事故パターン1：途中で壊れたまま放置される🧨​

「一時的に壊れてても、あとで直すから…」って設計は危険⚠️ 例：

  • Withdraw で残高がマイナスになった
  • でも「後で調整するメソッド」を呼び忘れた → 壊れた口座がシステム内に残る😱

事故パターン2：別のメソッドが“壊れてない前提”で動いて爆発💣​

  • GetStatement() が「残高>=0」の前提で計算
  • 残高が -100 の状態が混入 → 表示が崩れる、例外、データ破損…😭

16.4 「不変条件はバグ」🧯🐞（仕様エラーじゃない）​

不変条件が破れるのは、ほぼ確実に👇

  • **開発者側のミス（契約違反）**🧑‍💻💥

ユーザー入力ミスみたいに「丁寧に返す」対象じゃなくて、 直すべきバグとして見つけやすくするのが大事だよ🔍✨

16.5 2026年のC#での現実的なやり方（大事）🧠🛠️​

2026年1月時点の最新ラインだと、.NET 10（LTS）とC# 14が現行として案内されてるよ📌✨ (Microsoft)

昔の「Code Contracts（コードコントラクト）」は .NET 5+（つまり現行の .NET）ではサポート対象外として案内されてるので、基本は使わない方針でOK🙅‍♀️💦 (Microsoft Learn) （System.Diagnostics.Contracts 自体のAPI説明は今もあるけど、実運用の主流にはなりにくいよ、という温度感） (Microsoft Learn)

なのでこの章では、今どきの王道👇でいくよ💗

  • 入口（public）でガード節🛡️
  • クラス内部は「壊れない更新手順」へ✨
  • 必要なら Debug時に不変条件チェックで即発見🐞🔔
  • テストで守る🧪🌈

16.6 実例：BankAccountで“不変条件”を体に入れる💰🏦✨​

不変条件を決めよう🧠📌​

このクラスは「口座」なので、最低限これ👇は守りたい：

  • Currency は null や空じゃない💴✅
  • Balance は 0以上💰✅

実装例（不変条件を壊さないクラス）🛠️✨​

using System;
using System.Diagnostics;

public sealed class BankAccount
{
    public string Currency { get; }
    public decimal Balance { get; private set; }

    public BankAccount(string currency, decimal initialBalance)
    {
        if (string.IsNullOrWhiteSpace(currency))
            throw new ArgumentException("Currency is required.", nameof(currency));
        if (initialBalance < 0)
            throw new ArgumentOutOfRangeException(nameof(initialBalance), "Initial balance must be >= 0.");

        Currency = currency;
        Balance = initialBalance;

        AssertInvariants();
    }

    public void Deposit(decimal amount)
    {
        if (amount <= 0)
            throw new ArgumentOutOfRangeException(nameof(amount), "Deposit amount must be > 0.");

        Balance += amount;

        AssertInvariants();
    }

    public void Withdraw(decimal amount)
    {
        if (amount <= 0)
            throw new ArgumentOutOfRangeException(nameof(amount), "Withdraw amount must be > 0.");

        // ここがポイント：不変条件（Balance >= 0）を壊さない更新しか許可しない
        if (Balance - amount < 0)
            throw new InvalidOperationException("Insufficient funds.");

        Balance -= amount;

        AssertInvariants();
    }

    [Conditional("DEBUG")]
    private void AssertInvariants()
    {
        Debug.Assert(!string.IsNullOrWhiteSpace(Currency), "Invariant failed: Currency must be set.");
        Debug.Assert(Balance >= 0, "Invariant failed: Balance must be >= 0.");
    }
}

ここが超重要ポイント💡✨​

  • Balance を private set; にして、勝手に外から壊せないようにした🔒
  • Withdraw で「マイナスになりそうなら拒否」して、壊れる道を塞いだ🚧
  • AssertInvariants() は Debug のときだけ動くから、開発中に即気づける🐞🔔

16.7 不変条件の「強さ」を上げるコツ3つ🧱💗​

コツ1：public setter を避ける（壊れる入口が増える）🚫🧨​

  • public decimal Balance { get; set; } これ、外からいつでもマイナスにできちゃうよね😵‍💫

コツ2：更新操作は“メソッド”に寄せる🏗️✨​

  • Withdraw / Deposit みたいに、意図が名前に出るようにする😊
  • ルールもそこに閉じ込められる🔒

コツ3：「一時的に壊して後で直す」をやらない🙅‍♀️💥​

不変条件は「いつ見ても守られる」だから、 途中で壊す設計は、だいたい事故る🧨😱

16.8 ちょい難：不変条件が重い場合（合計一致とか）🧾⚖️​

例：注文クラスで

  • 明細合計とTotalが一致してる みたいな不変条件を毎回チェックすると、件数によっては重いかも💦

そんなときは方針を分けるといいよ👇✨

  • **軽い不変条件（null禁止・範囲）**は常に守る✅

  • **重い不変条件（集計・整合）**は

    • 更新ルートを1本化する（集約ルート方式）🏛️
    • テストで強く守る🧪
    • Debug時だけ検証する🐞 みたいに設計でカバーする😊💗

16.9 ミニ演習（手を動かすやつ）📝🌸​

演習1：不変条件を3つ書く✍️✨​

次のクラスを想像して、不変条件を3つ考えてね👇

  • UserProfile（ユーザープロフィール）
  • ShoppingCart（カート）
  • EventSchedule（開始/終了がある）

例（カートなら）🛒

  • Items は null じゃない
  • 商品IDの重複は禁止
  • 個数は 1以上

演習2：壊れる入口を塞ぐ🔒🚪​

自分のコードでよく見る👇を探して、直してみよ😊

  • public set; が外に露出してるプロパティ
  • どこからでも List に Add できる公開コレクション

「更新はメソッド経由」に寄せるのが目標だよ🎯✨

演習3：Debugで不変条件チェックを入れる🐞🔔​

  • Debug.Assert を2つ入れてみよう
  • それを壊すテスト（または実行パターン）を作って、ちゃんと気づけるか確認✅

16.10 Copilot / Codex に頼るなら（速くて便利🤖⚡️）​

使えるお願い例💌✨​

  • 「このクラスの不変条件候補を箇条書きで10個出して」
  • 「不変条件を壊さないpublic API設計案を出して」
  • 「Debug.Assertを使ってInvariantチェックを追加して」
  • 「このクラスの不変条件を守るxUnitテストを提案して」

でも最後は人が握る✋🧠​

AIはたまに👇をやりがち😇💦

  • ルールを増やしすぎる（守れない不変条件を作る）
  • “一時的に壊す”設計を平気で出す だから、**「本当にいつでも守れる？」**で最終判断しよ😊✅

16.11 まとめ（この章の持ち帰り）🎁🌈​

  • 不変条件は「クラスの健康ルール」🏥🧱
  • 破れたらそれは基本「バグ」🐞💥
  • C#では カプセル化＋更新メソッド化＋Debugチェック＋テスト が王道🛠️✨
  • 「壊れる道を塞ぐ」設計がいちばん強い🔒💗

参考（最新情報の確認元）📚🔗​

  • .NET のサポートポリシー（.NET 10 のリリース日・LTS等） (Microsoft)
  • C# 14 の公式「新機能」ページ (Microsoft Learn)
  • Code Contracts のサポート状況（.NET 5+で非サポート案内） (Microsoft Learn)
  • System.Diagnostics.Contracts.Contract のAPIリファレンス (Microsoft Learn)