ポリモーフィズム5日目のゴール
5日目のテーマは 「同じ命令で違う動き」＝ポリモーフィズムを“アプリの判断ロジック”に活かすこと です。
1〜4日目で、 同じメソッド名で違う動きができる if/switch を消せる 未来の追加に強い 戦略を差し替えられる
という強力さを体験してきました。
5日目はさらに一歩進んで、 「条件分岐そのものをオブジェクト化する」 という、オブジェクト指向の本質に踏み込みます。
条件分岐を“オブジェクト”にするという発想
if/switch を書く代わりに「判断するオブジェクト」を作る
初心者がよく書くコードはこうです。
if (score >= 80) {
System.out.println("合格");
} else {
System.out.println("不合格");
}
点数によって判定を変える。 よくあるロジックです。
しかし、判定基準が増えるとどうなるか？
80点以上 → 合格 60点以上 → 再試験 それ以下 → 不合格
さらに増えると…
資格試験 模擬試験 社内テスト オンラインテスト
それぞれ判定基準が違う。
if が増える switch が増える メソッドが肥大化する
未来が地獄です。
ここでポリモーフィズムの出番です。
例題：判定ロジックを「オブジェクト化」する
Judge の judge() が試験ごとに違う動きをする
まず、共通インターフェースを作ります。
public interface Judge {
String judge(int score);
}
資格試験の判定。
public class LicenseJudge implements Judge {
@Override
public String judge(int score) {
return score >= 80 ? "合格" : "不合格";
}
}
模擬試験の判定。
public class MockJudge implements Judge {
@Override
public String judge(int score) {
if (score >= 70) return "A判定";
if (score >= 50) return "B判定";
return "C判定";
}
}
社内テストの判定。
public class CompanyJudge implements Judge {
@Override
public String judge(int score) {
return score >= 60 ? "合格" : "不合格";
}
}
使う側はこう。
public class JudgeService {
private Judge judge;
public JudgeService(Judge judge) {
this.judge = judge;
}
public void execute(int score) {
System.out.println(judge.judge(score));
}
}
ここで起きていることは、
判定ロジックそのものをオブジェクト化している ということです。
資格試験にしたければ：
JudgeService service = new JudgeService(new LicenseJudge());
模擬試験にしたければ：
JudgeService service = new JudgeService(new MockJudge());
社内テストにしたければ：
JudgeService service = new JudgeService(new CompanyJudge());
使う側は永遠に同じ命令。
service.execute(75);
これが、 「同じ命令で違う動き」＝判断ロジックの差し替え です。
重要ポイントの深掘り：ポリモーフィズムは「条件分岐の外出し」
if/switch を“書かない”のではなく“外に出す”
ポリモーフィズムの本質は、 if を消すことではありません。
本質は、
条件分岐を“使う側”から追い出して、 “判断するオブジェクト”に閉じ込めること。
使う側は永遠に同じ命令だけ使う。 判断ロジックはオブジェクトの中に閉じ込める。 新しい判定基準が増えても使う側は変わらない。
これが、 オブジェクト指向の「判断ロジックの分離」です。
例題：割引計算を「同じ命令で違う動き」にする
Discount の apply() が割引方法ごとに違う動きをする
共通インターフェース。
public interface Discount {
int apply(int price);
}
定額割引。
public class FixedDiscount implements Discount {
@Override
public int apply(int price) {
return price - 500;
}
}
定率割引。
public class RateDiscount implements Discount {
@Override
public int apply(int price) {
return (int)(price * 0.9);
}
}
特別割引。
public class SpecialDiscount implements Discount {
@Override
public int apply(int price) {
return price - 2000;
}
}
使う側はこう。
public class DiscountService {
private Discount discount;
public DiscountService(Discount discount) {
this.discount = discount;
}
public int execute(int price) {
return discount.apply(price);
}
}
割引方法を変えたければ、 Discount を差し替えるだけ。
重要ポイントの深掘り：ポリモーフィズムは「ビジネスルールの差し替え」に使える
アプリの“ルール”をオブジェクト化するという発想
ビジネスアプリでは、 「ルール」が頻繁に変わります。
料金計算 割引計算 判定基準 検索条件 並び替え条件 フィルター条件
これらを if/switch で書いてしまうと、 変更のたびにコードが壊れます。
しかし、 ルールをオブジェクト化しておけば、
新しいルールを追加する 古いルールを差し替える
これらが 使う側のコードを変えずにできる。
これが、 ポリモーフィズムの“ビジネスアプリでの真価”です。
例題：フィルター処理を「同じ命令で違う動き」にする
Filter の apply() が条件ごとに違う動きをする
共通インターフェース。
public interface Filter {
boolean apply(String text);
}
長さフィルター。
public class LengthFilter implements Filter {
@Override
public boolean apply(String text) {
return text.length() >= 5;
}
}
キーワードフィルター。
public class KeywordFilter implements Filter {
@Override
public boolean apply(String text) {
return text.contains("Java");
}
}
禁止語フィルター。
public class NGWordFilter implements Filter {
@Override
public boolean apply(String text) {
return !text.contains("NG");
}
}
使う側はこう。
public class FilterService {
private Filter filter;
public FilterService(Filter filter) {
this.filter = filter;
}
public boolean execute(String text) {
return filter.apply(text);
}
}
フィルターを差し替えるだけで アプリの「判断基準」が丸ごと変わる。
5日目の実践：「条件分岐をオブジェクト化する」練習をする
if/switch を使っている処理を探して、ポリモーフィズムに置き換える
今日やってほしい練習は、 自分のコードの中から
「条件分岐で判断している処理」
を探すことです。
例えば、
割引計算 判定基準 検索条件 並び替え条件 フィルター条件
など、何でもOKです。
見つけたら、こう考えてみてください。
その条件分岐を オブジェクト化できないか？
共通インターフェースを作る 条件ごとにクラスを作る 使う側は同じ命令だけ使う
これができれば、 あなたのコードは一気に“中級のその先”に進みます。
5日目で本当に掴んでほしいこと
ポリモーフィズム5日目で伝えたいのは、 「同じ命令で違う動き」は “条件分岐そのものをオブジェクト化するための武器”だ ということです。
使う側は同じ命令だけ使う 条件分岐はオブジェクトの中に閉じ込める 新しい条件が増えても使う側は変わらない ビジネスルールを差し替えられる アプリ全体の構造が柔軟になる
これが、 オブジェクト指向の真の強さです。
6日目以降は、 このポリモーフィズムを 「アプリ全体のアーキテクチャ」にどう活かすかを学んでいきます。
