ISP――コピーの代役に、いいねの保存まで求めない

こんにちは、プロマリの紫です。連載「丸いボタンの裏側」の第7回、第2章の4回目です。SOLID は、変更に強いコードを書くための5つの原則を、頭文字でまとめた呼び名です。前回はその3つ目の原則 LSP を読み、「取り替えても、利用側が頼っていた約束が崩れないか」を確かめました。今回は4つ目の原則、ISPです。テーマはテストでコピーの代役を作るとき、いいねの保存まで書かされないかということ。小さな例で原則をつかんでから、プラグインの実物と、一時的な作業コピーでの実験で確かめます。

点線の付いた用語は、その言葉を押すと詳しい説明が開きます。意味、身近なたとえ、この実装での使い方を順に読めます。キーボードではTabで用語へ移動し、EnterまたはSpaceで開き、Escapeで本文へ戻れます。各ページで最初に出る用語から参照できるようにしました。

この記事は連載「丸いボタンの裏側」の第7回（2.4）です。前回の2.3「LSP――Copyに「開くURL」を要求すると何が壊れるか」で、取り替えても約束が崩れない形を先に読むと、今回の話がつながりやすくなります。連載全体の地図は、本編5ページ目の連載の目次からどうぞ。

この回は6ページあります。1ページ目で ISP の意味を、鳥とペンギンの短い例でつかみます。2ページ目でプラグインの実物を開き、ブラウザの機能を使うための口が5つの小さなインターフェースに分かれていることを確かめます。3ページ目でテストの代役を読み、もし全部入りの1つにまとめていたら代役に何が要るかを、一時的な作業コピーで試します。4ページ目では、いいねの保存がどの口にも入っていない理由を、5ページ目では分ける単位と分けすぎの代償を考え、6ページ目で前回の LSP とのつながりと宿題に進みます。図は15点です。実験の結果として載せるエラーの文面や件数は、すべて実際に手元で動かして取ったものです。

使わない能力まで、利用側に求めない

ISP は、日本語では「インターフェース分離の原則」と訳されます。最初に言葉にしたのは Robert C. Martin で、1996年に雑誌 The C++ Report の連載コラムに書いた記事では、次の一文で定義しています。「クライアントは、自分が使わないインターフェースへの依存を強いられるべきではない（Clients should not be forced to depend upon interfaces that they do not use.）」。

ここで言うクライアントは、お客さんのことではありません。あるインターフェースを使って仕事をする側のコード、この記事の言葉でいう利用側のことです。Martin は2020年の記事で、同じ原則をもっと短く言い直しています。「インターフェースを小さく保ち、使う人が必要のないものに依存しないようにする（Keep interfaces small so that users don’t end up depending on things they don’t need.）」。

身近なもので言えば、申込書です。コピー店で文書を1枚印刷してもらいたいだけなのに、申込書に「配送先の住所」「支払い方法」「会員番号」の欄があり、どれも必須だったらどうでしょう。印刷には関係ないのに、全部を埋めないと受け付けてもらえません。しかも、配送のルールが変わって欄が1つ増えたら、印刷しか頼まない人まで、新しい申込書に書き直すことになります。ISP が避けたいのは、この「使わない欄の必須」です。

共有ボタンでいえば、コピーのボタンです。コピーの処理に要るのは、「文字列をクリップボードに書き込む」能力だけです。ところが、いいねの保存やアクセスの記録まで1つのインターフェースに入れてしまうと、テストでコピーの代役を作るだけで、いいねの保存まで書かされることになります。この回の題名は、ここから来ています。

なぜ、使わない能力に頼ってはいけないのか

Martin は1996年の記事で、理由をこう説明しています。使わないインターフェースに頼らされている利用側は、そのインターフェースが変わるたびに影響を受ける。ほかの利用側の都合で変わった部分に、自分まで巻き込まれる、ということです。本来は無関係なはずの利用側どうしが、同じインターフェースを通して、知らないうちにつながってしまいます。

守らないと、具体的には3つのことが起きます。1つ目に、テストで代役を作るたびに、使わない能力の分まで中身を書くことになります。2つ目に、使わない能力が変わるたびに、関係のない利用側まで直すことになります。申込書の欄が増えて、印刷の人まで書き直すのと同じです。3つ目に、使わない能力のために「例外を投げるだけ」や「何もしない」の中身が増えます。そうした中身は、取り替えたときに壊れる実装の温床になります。これは、このページの最後で前回の LSP とつなげて読みます。

まず一般的な例：飛べない鳥に fly を求める

原則を実物に当てる前に、よく使われる例で形をつかんでおきます。鳥を表すインターフェース Bird に、「飛ぶ（fly）」と「泳ぐ（swim）」の2つのメソッドを持たせた例です。この連載で使っている TypeScript で書きました。

interface Bird {
  fly(): void;
  swim(): void;
}

class Duck implements Bird {
  fly(): void { console.log('カモが飛ぶ'); }
  swim(): void { console.log('カモが泳ぐ'); }
}

class Penguin implements Bird {
  fly(): void { throw new Error('ペンギンは飛べません'); }
  swim(): void { console.log('ペンギンが泳ぐ'); }
}

const birds: Bird[] = [new Duck(), new Penguin()];
birds.forEach((bird) => bird.fly());

上から読んでいきます。最初の4行が interface Bird で、「鳥なら fly と swim の両方を持つ」という約束です。次のカモ（Duck）は、飛ぶことも泳ぐこともできるので、両方を素直に書けます。困るのはその次のペンギン（Penguin）です。ペンギンは飛べませんが、Bird の約束がある以上、fly を書かないと型チェックを通りません。しかたなく、fly の中身は「ペンギンは飛べません」という例外を投げるだけにしています。最後の2行では、カモとペンギンを Bird の並びに入れ、まとめて飛ばしています。

このファイルを、型チェックと実行の両方にかけてみました。型チェック（tsc --noEmit --strict --target ES2022 --lib ES2022,DOM fat.ts）は、何も言わずに通りました。約束の上では、ペンギンも「飛べる鳥」だからです。ところが実際に動かす（node fat.ts）と、「カモが飛ぶ」と表示したあと、ペンギンの番で Error: ペンギンは飛べません と例外が出て止まりました。壊れていることが分かるのは、飛ばした瞬間です。もしこれがボタンの処理なら、利用者が押したときに初めて分かることになります。

約束を、能力ごとに分ける

ISP に沿って直すと、「飛ぶ」と「泳ぐ」を、Flyer と Swimmer という2つの小さなインターフェースに分けます。

interface Flyer {
  fly(): void;
}

interface Swimmer {
  swim(): void;
}

class Duck implements Flyer, Swimmer {
  fly(): void { console.log('カモが飛ぶ'); }
  swim(): void { console.log('カモが泳ぐ'); }
}

class Penguin implements Swimmer {
  swim(): void { console.log('ペンギンが泳ぐ'); }
}

function flyAll(birds: Flyer[]): void {
  birds.forEach((bird) => bird.fly());
}

flyAll([new Duck()]);
flyAll([new Penguin()]);

最初の2つのかたまりが、飛ぶ能力の約束 Flyer と、泳ぐ能力の約束 Swimmer です。カモは両方を名乗り（implements Flyer, Swimmer）、ペンギンは Swimmer だけを名乗ります。ペンギンに、意味のない fly を書く必要はもうありません。flyAll は「飛ぶ能力を持つものの並び」だけを受け取る関数です。最後の行で、わざとペンギンを flyAll に渡してみました。

今度は動かす前に、型チェック（tsc --noEmit --strict --target ES2022 split.ts）が split.ts(23,9): error TS2741: Property 'fly' is missing in type 'Penguin' but required in type 'Flyer'. と言って止めました。「Penguin には fly が無いが、Flyer では必要だ」という意味です。分ける前と比べると、壊れていることに気づく時点が、動かしたあとから、動かす前へ移りました。

例外を投げるだけの実装は、分けどきの合図

ペンギンの fly のように、「例外を投げるだけ」「中身が空」「何もしないで決まった値を返すだけ」のメソッドを見つけたら、インターフェースが大きすぎる合図です。書かされているのは、その実装にとって要らない約束だからです。何でも入ったインターフェースにはFat インターフェースという呼び名があり、避けるべき形とされています。Martin の1996年の記事も、結論で fat interface（太ったインターフェース）の欠点を挙げ、本来は切り離されているべき利用側どうしを結び付けてしまう、と書いています。

ペンギンの fly は、もう1つの原則にも反しています。前回読んだLSPです。Bird の並びを受け取った利用側は、「鳥なら飛べる」という約束に頼っています。そこへペンギンを渡すと、同じ Bird なのに例外が出て、約束が崩れます。例外を投げるだけの実装や空の実装は、ISP の問題であると同時に、LSP の問題でもあるのです。ISP で約束を分けておけば、ペンギンにそもそも fly が求められないので、LSP を破る余地も生まれません。