11
Help us understand the problem. What are the problem?

More than 1 year has passed since last update.

posted at

updated at

マンガでわかる Interpreter

F6F1CB4E-161C-41BD-831F-478F0D1D767B.png

あやうくシナリオライターの気まぐれのせいで、発売直前に何度も再コンパイルさせられる、地獄のデスマになるところでした。

Interpreter パターンは GoF のデザインパターンの中で、もっとも異色の存在です。メイン開発言語で柔軟性が得られないときは、別の言語インタプリタを使いなさいなんていう、ずいぶん乱暴な (オブジェクト指向と関係ないじゃんと思えるような ← だから何度も言ってるとおり、OOP 言語のためだけのものじゃないんですよこれ) 設計方針です。

...と思うでしょ。でもこれ、なんのことはない、別の言語で書かれた設定ファイルを使いましょう、あるいは、できるプログラマーは他の人でも書ける DSL のプロセッサーを作っておくようにすると楽ですよ、っていう、ごく普通のことを言っています。

Interpreter が処理する言語は、用をなすなら、条件分岐や繰り返しなんてなくてもかまいません。GOTO ジャンプだって場合によってはあり (ゲームのシナリオなんてとくに) です。上から下に逐次処理でなくても、XML/YAML で宣言された定義の依存をたどって、順序を再構成したってかまいません。もとが軽量言語なら、その文法パーサーを拝借して Array と HashMap のリテラル使った DSL だってかまわないでしょう。

ともかく、メイン開発言語のフル機能ではない、より簡易なプログラムコード的なものを、 Command の列をオブジェクトで表現し、それらを実行できるようにした仕組みというのは、柔軟性をすごく上げるよって、それだけなんです。

あ、外部設定ファイルといっても、変数名と値を結びつけるだけの ‘.env’ みたいなものはさすがに Interpreter とは言えませんよ。あと、軽量言語の言語内 DSL と言いながら、メイン言語を完全に習得していないと書けないようなものも、ちょっと違いますよね。何が目的だったか、よく考えましょうってことです。

Why not register and get more from Qiita?
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away
Sign upLogin
11
Help us understand the problem. What are the problem?