読者です 読者をやめる 読者になる 読者になる

糸電話式のアレ

プログラミングのこと。毎日のこと。書いています。

最近はGroovyらしさとか気にしない。

Groovy

どうしてOOPちゃんとやるとifって使う機会ないよね?

ちょっと読んだブログの記事の影響で、OOP的なコードを書いて見たくなりました。

まぁ、何がOOP的なのかというのは難しい問いなので、
if文を使わずに、マリオを敵にぶち当てたときの振る舞いを定義する。

ということをやります。

元記事がJavaの想定だったので、ほんのちょっとJavaで動かそうとか思ってました。
そのため、Groovyらしくないコードになっていますがご容赦を。

あと、特に意図はありませんが、今回のプログラムでは命名には日本語を使用しています。
ただし一部のクラス名には、Groovyコンパイラの制限から開始文字を英字にしているものがあります。
(具体的に言うと、変数やメソッドや関数の返り値の宣言時に、日本語名を型として使う場合に引っかかるようです。ただし、引数の型の場合はOKでした)

2つのアプローチでマリオを定義しよう

マリオを抽象化するアプローチ

抽象的なマリオクラスを用意して、それのサブクラスとしてチビマリオ、デカマリオ、無敵マリオ、そして、死体のマリオを、そのサブクラスとして実装します。

マリオ自身を抽象化するって感じですね。

さて、この実装だと、マリオの状態が追加されたりするたびにマリオサブクラスを作成する必要があります。
しかも、使用時にはマリオインスタンスが増えていく始末。
マリオは量産品ではないので、この実装はなんとなく嫌な感じがしますね。

マリオの振る舞いを抽象化する

マリオをSingletonで実装しておき、マリオの振る舞いを抽象化してみましょう。

ほとんどの振る舞いは状態を表すEnumクラスの"Eマリオ状態"に持たせることにします。
ついでに、マリオの振る舞いはInterface化して、"Iマリオ行動"としておきましょう。
ついでにマリオ状態の変化をゲームに近いものとするため、マリオには"アイテムとる"メソッドを実装してアイテムによるマリオ状態の変化を行わせましょう。

上記のように、Singletonなマリオの唯一のインスタンスにアイテムを与えたり、敵に触れさせることでマリオの状態が変更出来る様になりました。

Eマリオ状態の大きさが少し気になりますが、この辺はちゃんと考えれば色々やりようはあるでしょう。

状態変化の対応表をHashTableとしてもたせているあたりは、Javaとの互換性をもたせた方法で行なっているのでちょっとダサイです。

Eマリオ状態とマリオはIマリオ行動を実装しています。
特に深く考えてやったわけではないのですが、この実装はどうなんでしょうね?
あまり良い実装ではないような気がします。

まだまだ修行が必要だなぁ。