あやうくシナリオライターの気まぐれのせいで、発売直前に何度も再コンパイルさせられる、地獄のデスマになるところでした。
Interpreter パターンは GoF のデザインパターンの中で、もっとも異色の存在です。メイン開発言語で柔軟性が得られないときは、別の言語インタプリタを使いなさいなんていう、ずいぶん乱暴な (オブジェクト指向と関係ないじゃんと思えるような ← だから何度も言ってるとおり、OOP 言語のためだけのものじゃないんですよこれ) 設計方針です。
...と思うでしょ。でもこれ、なんのことはない、別の言語で書かれた設定ファイルを使いましょう、あるいは、できるプログラマーは他の人でも書ける DSL のプロセッサーを作っておくようにすると楽ですよ、っていう、ごく普通のことを言っています。
Interpreter が処理する言語は、用をなすなら、条件分岐や繰り返しなんてなくてもかまいません。GOTO ジャンプだって場合によってはあり (ゲームのシナリオなんてとくに) です。上から下に逐次処理でなくても、XML/YAML で宣言された定義の依存をたどって、順序を再構成したってかまいません。もとが軽量言語なら、その文法パーサーを拝借して Array と HashMap のリテラル使った DSL だってかまわないでしょう。
ともかく、メイン開発言語のフル機能ではない、より簡易なプログラムコード的なものを、 Command の列をオブジェクトで表現し、それらを実行できるようにした仕組みというのは、柔軟性をすごく上げるよって、それだけなんです。
あ、外部設定ファイルといっても、変数名と値を結びつけるだけの ‘.env’ みたいなものはさすがに Interpreter とは言えませんよ。あと、軽量言語の言語内 DSL と言いながら、メイン言語を完全に習得していないと書けないようなものも、ちょっと違いますよね。何が目的だったか、よく考えましょうってことです。