DSL / DSL Lifecycle

DSL

DSL Lifecycle(DSLライフサイクル) †

一言要約 †

DSLを構築するアプローチは複数あるが、初めにDSLをラフスケッチし、フレームワークとDSLの定義を交互に進めていく方法を好む。

要約 †

• DSLを作成する2つのアプローチ
  • フレームワークとそれを利用するコマンドクエリーAPIを作成してから、DSLを作成する
  • 最初にDSLを定義する

• 初めにDSLを定義する方法にも、2つの方法がある
  • 最初から厳密な構文で作成する
  • ラフに作成して段々と形式を整える 　
• 本書のステートマシンの例で考えれば、顧客とのコミュニケーションや要望の想像からコントローラの例を思いついて、それをDSLで記述することで擬似的なDSL(DSLのラフスケッチ？)を得られる。

• 本書の例を試すには言語ワークベンチは使用しないせず、通常のエディタを使用すること

• DSLのラフスケッチから実装を進めていく3つの方法がある
  • フレームワークとDSLを交互に少しずつ組み立てる
  • フレームワークを構築してから、それを利用するDSLを定義する
  • 最初にDSLを定義してからフレームワークを構築する

• ファウラーは漸進派なので、最初の方法をとる。
  • フレームワークの作成(テスト駆動で)、DSLの定義、フレームワークへのフィードバックをコントローラひとつずつ繰り返していく

• 最初にDSL必要と確信していない場合も、フレームワークを構築し、長く使用して新規顧客が適応するのが難しくなってくるとDSLを試そうとする。

• いくつコントローラを構築しているがフレームワークの存在を気づいていない場合も多い。その場合、最初にモデルと設定コードを分離することに集中する方法がある。

• 他にはDSLをプロセッサーでコントローラのコードに変換する方法もある。コードをきれいにはしないが、コントローラの追加は簡単になる。リファクタリングもできないボロボロのコードに対して有効。

ファウラーへのフィードバック †

担当者のつぶやき †

• 内容は単純のはずなのに難しい(特にパラグラフ間のつながり)
• 最初にDSLを使用しないで開発を進めると、長く使うモデル、フレームワークでないとDSLは適用しづらい？

みんなの突っ込み †