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は適用しづらい?
みんなの突っ込み †