DSL
グラント嬢のコントローラのプログラミング †
要約 †
[コントローラの実装例(java)]
- 前節のコード(前半)と本節のコード(後半)の違い
- 前半:ステートマシンの構築(ライブラリ、フレームワーク、コンポーネントの実装コード)
- 後半:ステートマシンモデルの構成方法(構成やコンポーネントの組み立て)
- この違いの本質的な部分は変わりやすい部分から共通部分を分離すること
[XMLによるコード例]
- XMLによる実装の利点
- コントローラ毎にコンパイルせず、動的にXMLファイルを読み込むことができる
- 動作変更がコンパイルなしに実行できる。(逆に言えば実行時に誤りが検出される)
- 宣言的なアプローチによる表現力UP。可読性が上がりミスが減る
[独自構文のコード例]
- ファウラー独自の可読性、記述性にこだわった構文のコード例。
- 構文は自分で作り出せる(ランタイムに読む込むのでも、コンパイル時に読み込むのでも)
- 独自構文のコード例は特定の狭い目的に特化している点など多くの点でDSLの特徴を保持している
- 適用範囲が狭いのでアプリケーション全体を記述するには他の言語が必要
- XMLの例もDSL。独自構文に比べてパースに慣れているが、独自構文のほうが可読性が高い。これがトレードオフの中心の一つ。
[Rubyのコード例]
- Rubyの力でより読みやすい構文を実現できる。(LispプログラマーがDSLを構築しているのと同じ考え方)
- 2種類のDSL
- 外部DSL: メインで動作する言語とは別の言語で表現されるドメイン固有言語(独自構文やXML)
- 内部DSL: 一般用との言語の構文で表現される
- 組込(Embeded)DSLは組込言語(embeded language)という言葉があるので、ここでは内部DSLに統一する。
- 最初のJavaのコード例は通常のAPIと密接でDSLではない。だが不可能というわけではない。
[流れるインターフェースによるコード例]
- この例は最近流行の流れるインターフェースで、ちゃんとしたJava。
- Rubyほどではないが宣言的な部分がありDSLといっていい(内部DSL)。
- 通常のAPIと流れるインターフェースの違いは難しい。この後長い考察になる。
- コマンドクエリAPIという言葉を用いることとする。(by ファウラー)
担当者のつぶやき †
- 流れるインターフェースでDSLを書こうとするのは、空白や"."の位置にちょっと無理やり感を感じてしまいます。
みんなの突っ込み †
- panalCloseってリセットイベントにならないんでしょうか? -- 池田?