ポリモーフィズム7日目のゴール
7日目のテーマは 「同じ命令で違う動き」＝ポリモーフィズムを“自分の設計ポリシーとして言語化する”こと です。
ここまで6日間で、ポリモーフィズムの
- 魔法のような動き
- if/switch を消す力
- 未来の追加に強い構造
- 戦略の差し替え
- ビジネスルールの外出し
- 分岐そのものの消滅
を体験してきました。
7日目は、これらを 「自分はこういうときにポリモーフィズムを使う」 と説明できるレベルまで持ち上げます。
ポリモーフィズムの本質を一言で言うと
「使う側は同じ命令だけ使い、違いはオブジェクトに閉じ込める」
ポリモーフィズムを一言でまとめるなら、これです。
使う側は同じ命令だけ使う。 違いはオブジェクトの中に閉じ込める。
この構造があるだけで、
- 分岐が消える
- 使う側のコードが永遠にシンプル
- 新しい種類が増えても壊れない
- 変更に強い
- テストしやすい
- アプリの構造が柔軟
というメリットが一気に手に入ります。
例題：アプリ全体を「同じ命令で違う動き」で設計する
Notification、Payment、Filter、Plan…すべて同じ構造で設計できる
ここまで学んだ例を振り返ると、 すべて同じ構造で設計できていることに気づきます。
Notification の send()
public abstract class Notification {
public abstract void send();
}
Payment の pay()
public interface Payable {
void pay(int amount);
}
Filter の apply()
public interface Filter {
boolean apply(String text);
}
Plan の calculate()
public interface Plan {
int calculate(int base);
}
Sorter の sort()
public interface Sorter {
List<Integer> sort(List<Integer> list);
}
これらはすべて、
「共通の命令」＋「種類ごとの違い」 という構造になっています。
使う側は永遠に同じ命令だけ使う。
重要ポイントの深掘り：ポリモーフィズムは「アプリの拡張性」を保証する
新しい種類を追加しても、使う側は変わらないという設計
ポリモーフィズムの最大の価値は、 「新しい種類を追加しても使う側のコードが変わらない」 という点です。
例えば、Notification に LINE 通知を追加しても、
public class LineNotification extends Notification {
@Override
public void send() {
System.out.println("LINE通知送信");
}
}
使う側は変わりません。
n.send();
Payment に PayPay を追加しても、
public class PayPayPayment implements Payable {
@Override
public void pay(int amount) {
System.out.println("PayPayで支払い");
}
}
}
使う側は変わりません。
p.pay(1000);
Filter に新しい条件を追加しても、
public class EmojiFilter implements Filter {
@Override
public boolean apply(String text) {
return text.contains("😊");
}
}
使う側は変わりません。
filter.apply(text);
この「使う側が変わらない」という構造こそ、 ポリモーフィズムの真価です。
例題：アプリの「流れ」そのものをポリモーフィズムで差し替える
Processor の process() がアプリの流れを決める
共通インターフェース。
public interface Processor {
void process();
}
ログ処理。
public class LogProcessor implements Processor {
@Override
public void process() {
System.out.println("ログ処理を実行");
}
}
データ同期処理。
public class SyncProcessor implements Processor {
@Override
public void process() {
System.out.println("データ同期を実行");
}
}
バックアップ処理。
public class BackupProcessor implements Processor {
@Override
public void process() {
System.out.println("バックアップを実行");
}
}
使う側はこう。
public class AppRunner {
private Processor processor;
public AppRunner(Processor processor) {
this.processor = processor;
}
public void run() {
processor.process();
}
}
アプリの「流れ」を変えたければ、 Processor を差し替えるだけ。
重要ポイントの深掘り：ポリモーフィズムは「設計の軸」になる
if を消すためではなく、アプリの構造を美しくするために使う
ポリモーフィズムは 「if を減らすための仕組み」ではありません。
本質は、
アプリの構造を美しくし、 変更に強くし、 拡張に強くし、 使う側のコードを永遠にシンプルにするための設計の軸。
この軸を持てていると、 どんなアプリでも「種類が増えても壊れない」構造にできます。
7日目の実践：「自分のポリモーフィズムポリシー」を言語化する
次の3つを自分の言葉で説明できれば“中級のその先”です
今日やってほしいのは、 次の3つを自分の言葉で説明することです。
1. どんなときにポリモーフィズムを使うか
例： 「種類ごとに違う動きをさせたいとき」 「if/switch が増えそうなとき」 「未来の追加に強い設計にしたいとき」
2. ポリモーフィズムのメリット
例： 「使う側のコードが変わらない」 「分岐が消える」 「戦略を差し替えられる」 「ビジネスルールを外出しできる」
3. ポリモーフィズムを使うときの注意点
例： 「共通の命令を正しく設計する」 「種類ごとの違いをクラスに閉じ込める」 「使う側が種類を意識しない構造にする」
この3つを説明できれば、 あなたはもう「ポリモーフィズムを知っている人」ではなく “ポリモーフィズムを設計の武器として使える人” です。
7日目で本当に掴んでほしいこと
ポリモーフィズム7日目で伝えたいのは、 「同じ命令で違う動き」は “自分の設計ポリシーとして使える”ということ です。
使う側は同じ命令だけ使う 違いはオブジェクトの中に閉じ込める 新しい種類が増えても壊れない アプリの構造が柔軟になる 未来の変更に強い 戦略を差し替えられる ビジネスルールを外出しできる
これらを自分の言葉で説明できれば、 あなたはもう“中級”のその先に進んでいます。
次のステップでは、 このポリモーフィズムを 「アプリ全体のアーキテクチャ」にどう活かすかを さらに深く学んでいきましょう。
