【Aモデル録 フェーズ1 C#基礎】

07-05:static の使いどころ・注意点・設計的立ち位置

―「使えるけど、乱用すると壊れる」道具―

一言で言うと

👉 static は「オブジェクトに属させる意味がない処理」を置く場所です。

便利だから使うものではありません。
設計上、そこに置く必然があるときだけ使うものです。

まずは、大前提の再確認（超重要）

あなたはもう、ここまで来ています。

• static メンバーは クラスに属する
• インスタンスメンバーは オブジェクトに属する
• プログラム開始時、オブジェクトは存在しない
• だから Main は static = オブジェクトが存在しなくても呼び出しができる

👉 static は例外ではなく、所属ルールの一部

ここから先は、
「じゃあ、いつ、なにを static にするのが正解か？」の話です。

static が向いている処理（王道）

① 状態を持たない処理（純粋な処理）

class MathUtil
{
    public static int Add(int a, int b)
    {
        return a + b;
    }
}

int result = MathUtil.Add(3, 5);

• 記憶しない
• 状態を持たない
• 入力 → 出力だけ

👉 どのオブジェクトの仕事でもない

こういう処理は、
static にする意味がある。

② クラス全体に共通のルール・定数

class GameSetting
{
    public static int MaxPlayer = 4;
}

• 全員が同じ値を見る
• 個体差が存在しない

👉 「1つであるべきもの」

これが static の適材適所。

③ プログラムの入口・補助役

• Main
• Console.WriteLine
• ユーティリティクラス

👉 「最初からオブジェクトを前提にできない」世界

static が必要になります。

static が向いていない処理（重要）

ここが一番大事です。

❌ 状態を持つもの

class Dog
{
    public static int Age;
}

これ、何が起きるか。

• 犬Aも
• 犬Bも
• 同じ Age を共有する

👉 犬が1匹に融合してしまう

設計崩壊です。

❌ 「クラス独自の、能力のうちのひとつ」なのに static

class Dog
{
    public static void Bark() { }
}

Dog.Bark();

👉 「犬がいないのに吠えさせる」

= 「オブジェクト」に属していない

これは、
static が悪いのではなく、
役割の選択ミス。

よくある誤解（ここで潰す）

❌ static = new しないから特別
❌ static = 便利。魔法。
❌ static = とりあえず付けるもの

→ 全部違う

👉 static は
「この処理は、オブジェクトに属させる意味が無い」
と判断した結果、選ばれるもの。

判断基準（Aモデル式・実践）

static にする前に、これを自問してください。

「この処理、
“1つのモノ”に属していると言えるか？」

• YES → インスタンスメンバー
• NO → static 候補

超短い、実践向きまとめ

• static は「クラスに属する」
• 状態を持たない「処理」向き
• 共通ルール・補助処理向き
• モノの能力は static にしない
• 便利だから使うと、設計が壊れる

最後に

static は、
強いけど、不器用な道具です。

正しく使うと設計が締まり、
雑に使うと、後で必ず苦しみます。

だからこの回は、

「static を怖がらず、
でも敬意を持って扱う」

ための回。

構成と読み方｜タイトル一覧

Top - はじめに｜この忘備録と｢Aモデル｣について