フレームワークとは何か(2)

上のほうにも書いたが、フレームワークとはフレーム、仕事の枠なのである。枠って何さ、と思うかもしれないが、つまりは習慣でありコーディング上の規則だ。だが、コーディング規約というものとは少し違う。
コーディング規約というのは会社などで、例えばGOTO文の禁止や、while文の条件判定に関する規則などを独自に定め、その上でコーディングを行なうように指示することを言う。フレームワークはその発展形といえるかもしれない。実際にコーディングをする際に、その枠からそもそも出てコーディングすることが難しい状態を作り上げてしまうのだから。だが、決してフレームワークは不便さを押し付けるものではない。生産性を上げ、なおかつ保守を容易にするために生み出されているものだ。
フレームワークを考える際に、一つ問題が生じる。仕事の枠というものは、各プロジェクトごとに別である。あるプロジェクトの枠は、別のプロジェクトよりも狭いかもしれない。つまり例えばあるプロジェクトではデータベースを用いるが、別では用いないかもしれない。では、フレームワークとはどのレベルの枠を設定すればよいのだろうか。なるべく自由度を上げるために、大きな枠のみを作るべきなのだろうか、それとも逆に小さい枠まで作り上げていくべきなのだろうか。
この問題に対する解答はいくつかあるだろうが、これ以降ではまず機能が極めて少ないフレームワークを作り、それを拡張するという立場を取る。具体的には、まずテンプレート機能を作り、それに様々な機能(例えばDBへの接続や、メールの送信など)を付加していく。だがもちろん、多機能であれば良いということは無く、各プロジェクトでは必要な機能と不要な機能が存在すると考えられるので、その機能の取捨選択の方法及び基準を設定する。
もちろん、完成したスクリプトはどこかに公開するし、実際に使えるものになっていると思う。ただ、実際にスクリプトを書かなくてはいけないので、ちょっと時間がかかると思う。更新もそれほど頻繁には行なえないと思う。
ちょっと気になった人もいるかもしれないが、実際のコーディング自体は全てPerlで行なう。サンプルソースや、各言語における対応などでは、説明文中にJavaなどのソースを記述するかもしれないけれど。上でJavaを対照の言語としたのにはそこに理由がある。