守り方は、二通りしかない

「このメソッドは、nullを返さない」。

コードのどこにも書いていないのに、呼び出し側が当てにしている決まりが、どのコードにもあります。この記事では、これを仕様（または約束事） と呼びます。

仕様の守り方は、二通りしかありません。構造で守るか、規約で守るか。

構造で守る

構造で守るとは、仕様をコードの形に落としてしまうことです。
「nullを返さない」なら、戻り値の型をstring?ではなくstringにする。（補足、C#のnull安全の文脈）
もし仕様の約束事を破ればビルドが失敗するか、少なくとも警告が出ます。

規約で守る

規約で守るとは、仕様を

コメント、ドキュメント、命名
レビューとテスト

で見張ることです。

スライドの言葉でいえば『形で守るか、張り紙で守るか。』
　つまり「人間の注意力を燃やして」守ることです。

基準（物差し）にして仕分け

「構造で守るか、規約で守るか」を物差しにして、五原則を仕分けてみます。

開放閉鎖の原則（OCP）はこの軸に乗りません
　OCPは「守り方を選ぶ規則」ではなく、「変更せずに拡張できたか」という到達目標です。
単一責任の原則（SRP）も抽象度が違います
　スライドの言葉で言えば、運転手ごとに、車を分ける話。もし相席すると、別々の依頼が同じファイルに届くので、そこから違反を検知できます。

残る三つ。

当初、私は、三つは同じレベル感だと考えていました。

しかし「構造で守るか、規約で守るか」で見ると、少し違って見えます。

原則	形の整え方	違反すると
インターフェース分離の原則（ISP）	差込口を、細く割る	宣言にないメソッドは、呼びたくても呼べない
依存関係逆転の原則（DIP）	依存の向きを、参照で縛る	参照のない方向へは、ビルドが通らない

これらは構造で守れます。（構造図やコンパイラで違反を検知できるの意味です）

（メソッド名の綴りを変えればビルドで止まる、これはコンパイラで違反を検証できる例です。コンパイラは「構造で守る」の中でも一番安価な検証器です）

しかし、リスコフの置換原則（LSP）だけが、構造で守れません。

LSP定番の例で言えば、正方形は、長方形の形のまま「幅を変えても、高さは変わらない」という約束事を破ります。

言いたいのは、

どれだけインターフェースの形を工夫しても、振る舞いの仕様は形では守れません。守るには、言葉に書いたり、レビューを重ねるなど、人間の注意力を燃やして、見張るしかありません。

まとめると、『I・Dは、構造で守れる。Lは、規約でしか守れない。』

よくある売り文句が招く困りごと

『置き換え可能』はインターフェースの売り文句です。

実装を差し替えられます
モックに差し替えてテストできます
将来の実装に差し替えられます

しかしこれらは、すべて（先ほど見たように）構造では守れません。

フィールド名という「形」はコンパイラの管轄内。その先の置き換えられた実クラスの振る舞いは管轄外です。

検証する手段としてはテストをしっかり書くことです。しっかり書いているか注意して見守る必要があります。

保証書を発行しないという判断

ここから、設計判断の話になります。

いわば、インターフェースを一枚切ることは、保証書を一枚発行することです。
　『ここに挿さる実装は、どれを挿しても、同じように動きます。』という約束事です。

しかし、機械がチェックできるのは、シグネチャ（メソッドの名前と型の並び）だけ。
　「同じように動く」の部分を守るのは、規約とテスト、つまり、人間の注意力が燃料です。

そのため

まだ差し替えの予定がないインターフェース
いつか役に立つかもしれない再利用性
念のための置き換え可能性

こういった早すぎる実装は、保証書を乱発しているのと同じです。
であれば、インターフェース化を遅らせることは、遅らせた分だけ、より少ない注意力で回すこととなり、良い設計判断となりえます。

これは、確信のない機能は入れない、という設計方針（ミニマリティ）です。

もし、入れてしまえば、皆が必要性を考えずに使う。仮に、外しておいても、本当に必要なときには苦情が来る。

苦情駆動ですね。

後回しにできるもの、できないモノ

残念ながら、後回しにできるのは、保証書を発行するタイミングだけです。仕様を守ること自体は、後回しにできません。

守るべき仕様そのものは、消えないからです。もしも差し替えが必要になったら、規約（人間の注意力）で守るようにします。

発行するなら、三つの条件で

では、保証書を発行すると決めたら、どうやって守るのか？

そのヒントについての話しです。

規約で守る（人間の注意力が燃料）を補助する道具として、三つの条件があります。

呼び出しの入口を縛る「事前条件」
出口を縛る「事後条件」
いつ見ても成り立つ「不変条件」

スライド版で「形に書けない約束」と呼んだ三点セットです。

書き方と、破られ方の本体は、ここでは長くなりますので、契約による設計（Design by Contract / DbC）にゆずります。

さらに、もう一つ加えたいのが「一度確定した値は、以後変わらない」という条件。履歴制約です。

なぜか日本語版では説明が省かれているので英語版で、

Immutable Point/Mutable Point の議論です。これも発見が面倒な約束事の破り方です。

問い

そのインターフェース早すぎませんか

この記事について

先日、SOLID原則の設計原則を伝えるためのスライドを作成しました
　この記事はその「やさしく解説設計編・中級」を深掘りするものです。

中級#3「形は合っていたのに」

スライドについて

SOLID原則をやさしく伝えるためのスライドです。
例えるなら、このスライドは「守破離」でいえば、「守」になります。

この「守」では、まず審美眼を養うことを優先します。
そのため、語れなかったもの、省いたものが数多くあります。

今回は、「守」で説明した手段を「適用しない」場面について語ります。

つまり「破」の記事です。

守：スライド版「やさしく解説設計編・中級」

私の記事よりもわかりやすい記事：「シン・リスコフの置換原則〜現代風に考えるSOLIDの原則〜」（Uzabase for Engineers, 2026-04）