ワイ「オブジェクト指向っていまいちよく分かってないんだよね
そもそもなにが良くてそんなの使ってんの？」
友「わかる。フワフワしてなんだか掴みずらいよな」
ワイ「色々あるやん？継承とかカプセル化とかさ、ポリモーフィズムとか
ポリモーフィズムってなんやねん！もっとわかるような言葉にしろよw」
友「難しい言葉使えばえらい、みたいな節あるよな。でも意味自体はめちゃ単純やで」
ワイ「そうなん？」
友「うむ。オブジェクト指向って一言でいうと**"似たような奴らは仲間にしてまとめて、部品として再利用できるようにしてやろ"**ってことや」
ワイ「ほう」
友「オブジェクト指向じゃない世界を考えたらメリットがわかるぞ」
友「たとえばポケモンで考えるとするやん」
ワイ「俺の中ではポケモンはルビーサファイアで止まってるけどいい？」
友「ええよ。じゃミズゴロウ、アチャモ、キモリをコードで表してみて」
ワイ「こんな感じか」
ミズゴロウ;
ミズゴロウの図鑑No = 258;
ミズゴロウの特性 = "げきりゅう";
ミズゴロウのわざ = {"たいあたり","なきごえ","みずてっぽう"};
ヌマクローに進化する();{
ヌマクローになる;
}
アチャモ;
アチャモの図鑑No = 255;
アチャモの特性 = "もうか";
アチャモのわざ = {"ひっかく","なきごえ","ひのこ"};
ワカシャモに進化する();
キモリ;
キモリの図鑑No = 252
キモリの特性 = "しんりょく";
キモリのわざ = {"はたく","なきごえ","すいとる"};
ジュプトルに進化する();
友「うむ、なかなか詳しいな。なんか思うところはあるか」
ワイ「変数とかふるまいの名前が被らないようにするとどうしても名前が長くなってしまうな。まとめられるとこはまとめたい」
友「それがオブジェクト指向や。似た者同士まとめましょ、ってことやぞ。オブジェクト指向やとこうなる。
親クラスのポケモンを継承してミズゴロウとかを定義してるで」
abstract class ポケモン{
図鑑No;
特性;
わざ;
abstract 進化する();
}
class ミズゴロウ extends ポケモン{
図鑑No = 258;
特性 = "げきりゅう";
わざ = {"たいあたり","なきごえ","みずてっぽう"};
@Override
進化する(){
ヌマクローになる;
}
}
class アチャモ extends ポケモン{
図鑑No = 255;
特性 = "もうか";
わざ = {"ひっかく","なきごえ","ひのこ"};
@Override
進化する(){
ワカシャモになる;
}
}
class キモリ extends ポケモン{
図鑑No = 252;
特性 = "しんりょく";
わざ = {"はたく","なきごえ","すいとる"};
@Override
進化する(){
ジュプトルになる;
}
}
※実際に使うときはインスタンス化が必要です
ワイ「ほう。クラスで分けたら変数とかふるまいの名前が単純になったな」
友「うむ、それがポリモーフィズムや」
ワイ「！？？」
友「クラスに分けることでクラス毎に同じ名前の変数やふるまいを定義できるんや。」
友「例えばポケモンを進化させたい時を考えてみようか。ポケモンを継承したクラスのオブジェクトなら、指示を出す側はなにも考えず「進化する()」を呼び出すだけでええんや。ジグザグマ.進化する() とかね」
ワイ「そうか！？別に進化系がマッスグマってのを知らなくても進化させることができるんか」
友「せやで。ふるまいの実装は各ポケモンのクラスに任せて、呼び出す側は"進化する()"を実行するだけでいい。便利やろ(^^) これが"オブジェクト指向のメリット① ポリモーフィズム"や」
友「裏を返すと各ポケモンクラスは"進化する()"を独自に実装する"責任（お約束）"があるわけだ。まあこの辺りも話すと長いからまた今度やね」
つづく