ポリモーフィズム6日目のゴール
6日目のテーマは 「同じ命令で違う動き」＝ポリモーフィズムを“アプリの分岐そのものを消す仕組み”として使うこと です。
1〜5日目で、 同じメソッド名で違う動きができる if/switch を消せる 未来の追加に強い 戦略を差し替えられる ビジネスルールをオブジェクト化できる
という強力さを体験してきました。
6日目はさらに一歩進んで、 「アプリの分岐を“構造ごと”消す」 という、オブジェクト指向の最も美しい使い方に踏み込みます。
分岐を“構造ごと”消すという発想
if/switch を書かないのではなく「分岐という概念をなくす」
初心者がよく書くコードはこうです。
if (user.isPremium()) {
// プレミアム向け処理
} else {
// 通常ユーザー向け処理
}
しかし、ユーザーの種類が増えるとどうなるか？
通常ユーザー プレミアムユーザー 法人ユーザー 学生ユーザー 無料トライアルユーザー
if が増える switch が増える メソッドが肥大化する 未来が壊れる
ここでポリモーフィズムの本気が発揮されます。
例題：ユーザー種別ごとの処理を「同じ命令で違う動き」にする
UserType の process() が種別ごとに違う動きをする
まず、共通インターフェースを作ります。
public interface UserType {
void process();
}
通常ユーザー。
public class NormalUser implements UserType {
@Override
public void process() {
System.out.println("通常ユーザー向け処理");
}
}
プレミアムユーザー。
public class PremiumUser implements UserType {
@Override
public void process() {
System.out.println("プレミアムユーザー向け処理");
}
}
法人ユーザー。
public class CorporateUser implements UserType {
@Override
public void process() {
System.out.println("法人ユーザー向け処理");
}
}
使う側はこう。
public class UserService {
private UserType type;
public UserService(UserType type) {
this.type = type;
}
public void execute() {
type.process();
}
}
ここで起きていることは、
ユーザー種別ごとの分岐を、 UserType の中に閉じ込めている ということです。
使う側は永遠に同じ命令。
service.execute();
新しいユーザー種別が増えても、 使う側は一切変わりません。
重要ポイントの深掘り：ポリモーフィズムは「分岐の消滅」
if を消すのではなく「分岐という概念をなくす」
ポリモーフィズムの本質は、 if を減らすことではありません。
本質は、
分岐という概念を“使う側”から消すこと。
使う側は永遠に同じ命令だけ使う。 違いはオブジェクトの中に閉じ込める。 新しい種類が増えても使う側は変わらない。
これが、 オブジェクト指向の「分岐の消滅」です。
例題：料金計算を「同じ命令で違う動き」にする
Plan の calculate() が料金プランごとに違う動きをする
共通インターフェース。
public interface Plan {
int calculate(int base);
}
通常プラン。
public class BasicPlan implements Plan {
@Override
public int calculate(int base) {
return base;
}
}
プレミアムプラン。
public class PremiumPlan implements Plan {
@Override
public int calculate(int base) {
return base + 1000;
}
}
学生プラン。
public class StudentPlan implements Plan {
@Override
public int calculate(int base) {
return base - 500;
}
}
使う側はこう。
public class BillingService {
private Plan plan;
public BillingService(Plan plan) {
this.plan = plan;
}
public int execute(int base) {
return plan.calculate(base);
}
}
料金プランを変えたければ、 Plan を差し替えるだけ。
重要ポイントの深掘り：ポリモーフィズムは「アプリの分岐を外に出す」
分岐を使う側に書くとアプリが壊れる
料金計算を if で書くとこうなります。
if (type.equals("basic")) {
return base;
} else if (type.equals("premium")) {
return base + 1000;
} else if (type.equals("student")) {
return base - 500;
}
新しいプランが増えるたびに if が増える switch が増える メソッドが肥大化する
使う側のコードが壊れます。
しかし、 ポリモーフィズムならこう。
plan.calculate(base);
使う側は永遠に変わりません。
例題：ファイル読み込みを「同じ命令で違う動き」にする
FileReader の read() が形式ごとに違う動きをする
共通インターフェース。
public interface FileReader {
void read(String path);
}
CSV読み込み。
public class CsvReader implements FileReader {
@Override
public void read(String path) {
System.out.println("CSVを読み込み");
}
}
JSON読み込み。
public class JsonReader implements FileReader {
@Override
public void read(String path) {
System.out.println("JSONを読み込み");
}
}
XML読み込み。
public class XmlReader implements FileReader {
@Override
public void read(String path) {
System.out.println("XMLを読み込み");
}
}
使う側はこう。
public class FileService {
private FileReader reader;
public FileService(FileReader reader) {
this.reader = reader;
}
public void execute(String path) {
reader.read(path);
}
}
ファイル形式を変えたければ、 FileReader を差し替えるだけ。
6日目の実践：「分岐を構造ごと消す」練習をする
if/switch を使っている処理を探して、構造ごと置き換える
今日やってほしい練習は、 自分のコードの中から
「種類ごとに if/switch で分岐している処理」
を探すことです。
例えば、
ユーザー種別 料金プラン ファイル形式 割引方法 検索方法 フィルター条件
など、何でもOKです。
見つけたら、こう考えてみてください。
その分岐を オブジェクト化して構造ごと消せないか？
共通インターフェースを作る 種類ごとにクラスを作る 使う側は同じ命令だけ使う
これができれば、 あなたのコードは“分岐のない世界”に入ります。
6日目で本当に掴んでほしいこと
ポリモーフィズム6日目で伝えたいのは、 「同じ命令で違う動き」は “アプリの分岐そのものを消すための設計”である ということです。
使う側は同じ命令だけ使う 分岐はオブジェクトの中に閉じ込める 新しい種類が増えても使う側は変わらない アプリの構造が柔軟になる 未来の変更に強い
これが、 オブジェクト指向の真の力です。
7日目では、 このポリモーフィズムを 「自分の設計ポリシー」として言語化していきます。
