DSLs Chapter3

を読んだ。

Domain-Specific Languages (Addison-Wesley Signature Series (Fowler))

DSLsを実装した際のメカニズムの話。（Text DSLをパースして、Syntax Treeつくって、Semantic Modelをつくるパターンの話、textの文法の話。パース後に Syntax Treeをつくらない代わり、Symbol Teableのパターン、Macrosのパターンの話 ）

TDD好きなら、3.6 Testing DSLsがおすすめ。

１章の 状態遷移の例で話が進む。 xUnit Patterns の Custome Assertionなどを駆使して、act, assert部分を簡潔に記述したのち、まだ複雑さが残った arrangeの部分で DSLに書き換えるストーリー。

arrange 部分が 通常の Command-query APIじゃ 簡潔に書けない。かといって、DIコンテナ側のXMLでオブジェクトを組み立てるのも何か違うなぁは、私自身も何度か経験していた。
なんだか何かやだなーと思っていたので、うんうんと感じるところがある。

この例だと、独自文法の文字列が描かれていた。 過去のプロジェクトで、Expression Builderを試した事はあるが、今イチ使いこなせなかったのを思い出した。

その後、複雑な構造を持つオブジェクト群 を assertしたいときに役立ちそうなアプローチの話、DSLの記述が invalidなケースのテストの話が続く。

3.7 Handling Errors

学生時代に、スケジューリングのシミュレーションの 設定ファイルの記述に誤りがあった際に何処を修正すればよいのかわからず困ったこと、
社会人になってから、プロセス指向フレームワークの実行エンジンが実行不可不可であるアクティビティ図の記述の誤りをどうやったら 記述者にわかりやすく伝えられるか（タイトなスケジュールなので凝った事せずに）、
いろいろ悩んだことを思い出した。
私は、関与していないが、Yamlファイルのアプリケーション設定を 視覚化するツールをつくっているところは見た事がある。テキスト記述が期待通りかを 目で確かめやすくするためであろう。

3.8 マイグレーションの話

DSLsが published interfaceになっているか否かでアプローチが異なる話等、マイグレーションの作戦の話がちょろっと。