DSL

Sinatraで書くアプリケーションとか、Capistranoの設定とか、1ファイルでひたすら長くなっていく。構造化プログラミング的には、モジュールごとにファイルが分かれてて、スコープが分かれているとか、オブジェクト指向では、クラス単位で扱うけど、普通はクラスごとにファイルを分けるとか、そういう目安がある。

Sinatraでget '/'とか書くとき、Controllerは一つのクラスに全部書くという流儀だから、それより細かく分けたくなったときに、なめらかに分割しにくい。エンドポイントごとに分けると過剰な感じがする。

Capistranoも楽しくtaskを定義していくという形で、普通に使ってると分けにくい。taskごとに分けるとかすると過剰な感じがする。

(ファイル分割するのは自己責任というイメージで使ってるけど、公式のドキュメントで、コードが増えてきたらこういう指針で分割しましょうとか書いてあったら、教えてください)

SinatraもCapistranoも本体の実装は1ファイルということはなくて、適切なクラスたちが協調して動くようになってても、ユーザーに見えるのは簡単なDSLなので、普段のクラス分割リファクタリングみたいなことがしにくい。

DSLじゃなくて、メソッドを定義するくらいのパラダイムでAPIを提供する方がすっきりする気がする。DSLだと最初は適当に書けばいいけどその後の学習コストが高い。

ユーザーが定義する部分の全てがクラスとオブジェクトとして見えて、どこからどう呼ばれるか分かるようになってれば、その先はどう継承してもmix-inしても動くに違いないという状態になる。ユーザーが定義する部分は普通に使えばユーザーが設計を理解できるようになっているべき。フレームワーク部分の実装まで読まないと分からないのは、明文化されて設計や規約が存在しないのと同じで、バージョン上げたら内部構造が変わって壊れたりする。

追記

Sinatra は routing をモジュール化して register で組み合わせることができるので、Rails で書くときと同じくらいの粒度で分割することもある

— 一級河川 (@aereal) 2014, 2月 2

なるほど。