未確定の実装内容を別プラグインに切り出す【ツクールMV】

はいどーもこんにちはHaskellが全然わからない穀潰しです。
本日はプラグイン制作のコツというか、僕が実際の開発でよくやっていることを一つ紹介したいと思います。
それはズバリ、「未確定の実装内容を別プラグインに切り出す」ことです。
どういうことか見ていきます。

依頼者は仕様を確定しきれていないことがある

自分でプラグインを制作するときもそうなのですが、とりわけ誰かから「こんなプラグイン作れませんか?」と依頼があったとき、その「こんなプラグイン」の仕様をご本人が決めかねている場合がよくあります。
それは単に「ツミオとかいう野郎はこの難しそうな機能組めるんか? おお?」という場合もありますし、「こっちの機能もよさそうだけど、こっちも捨てがたい……。全体を通してバランスを考えてから決めたい」という時もあります。
いずれにせよ「仕様が未確定」です。
そんなとき、プラグインの本体に仮の実装を組み込んでもよいのですが、僕がおすすめするのは「実装内容が未確定の部分をインターフェイスだけ作っておいて、仮の実装内容を別プラグインに切り出しておく」ことです。

具体的にどういうことやねん

例えばプレイヤーが移動したとき、何らかのアクションを加えたいとします。
ですがその「何らかのアクション」は未確定です。
素直に考えるなら、コードはこんな感じになるでしょうか。

ですがこれだとあとから依頼者さんが「あの未実装って言っていたやつ、こうしてくれよ!」と言われた時、規模が大きいプラグインだと「どれのことだっけ?」と思い出すのに時間がかかってしまいます。
そこで僕がオススメするのが、以下のようなコードです。

ご覧のように、コメントで書いていた「なんらかのアクションを実装予定。本番では置き換える」という部分はメソッドとして抽出します(invokeMovingAction)。
これは「実装内容が未確定の部分をインターフェイスだけ作っておく」という部分ですね(本実装をする際、実装内容に合わせてメソッド名の変更も検討します)。
メソッド本体でエラーを投げるようにしているのがミソです。

が、これだと移動するたびにエラーが投げられてゲームになりません。
そこで次は「仮の実装内容を別プラグインに切り出しておく」作業をします。
というわけで別のプラグインファイルを適当に作って、以下のようなコードを書きます。

新たに作成したプラグインは、本体プラグインの下に設置します。
これで元のメソッドは完全に上書きされるため、エラーは発生しません。
ここではSEを鳴らすようにしている感じですね(仮の実装なんで何でもいい)。

何がよいのか

さてここまで読んで「わざわざ別プラグインに切り出さなくても、元のプラグインにSoundManager...を実装すればよいのでは?」と思った方もいるかもしれません。
確かにそれでも用をなします。
ただ最初にも書いたように、あとから見直したとき「どこを変更しなければならないのか」が明白ではありません。
また、「これは仮実装ですよ」というコメントをうっかり書き忘れたり、うっかり消したりした場合、「これはどういう意図で書いたコードだろうか?」と悩むことになります。

ところが別プラグインとして仮実装を切り出しておけば、「ここにあるメソッドは全て仮の実装で、本実装はまだなのだな」とわかります。
別プラグインのコードは全て仮実装のため、いちいち「仮実装のコードってどれとどれだったっけな」と覚える必要もありません。
また例えば仮実装のコードを間違って消したとしても、本実装がまだならば「throw new Error」されるはずなので、プログラムはそこで停止します。

問題点

この方法の問題点は、いちいち仮実装を別プラグインとして書くことが面倒なことですw
あとは、プラグイン制作者なら慣れているのでプラグインの導入順くらい問題にならないのですが、依頼者さんはそうでないことが多いので、「これってどういう風に使えばいいんですか?」的な質問をよくされます。
つまりややこしいw
実際、本実装完了後に仮実装のコードの更新を忘れてしまったことが僕も一度ありました(もちろんすぐに気がつくのですが)。

仮実装のコードを書くときの問題点もあります。
元のプラグインを即時関数で囲っている場合、グローバルな変数(もとい名前空間)などを用いて「即時関数の中」のコードにアクセスできるようにしていない場合、ビルトインされているクラス以外にアクセスできませんw
僕も昔はよく名前空間を作っていたのですが、最近は「めんどくせぇ」という理由でめっきり使っていないので、これは正直ちょっと困っています。
また名前空間復活させましょうかね……。

ちなみにですが、class構文を使っていてもきちんとコードの上書きは可能です。
なぜならclass構文はプロトタイプベース継承の糖衣構文だからです。

終わりに

本日は僕がよく使っている手法を一つ紹介してみました。
もっといい方法があるかもしれませんが、こんな書き方もあるんだよーという参考にしていただければなと思います。
ほなそんな感じでまた……。

フォローする