日々の破片

_ フレームワーク

フレームワークと大上段に構えたものって、製品（完成品と言おうか）であろうとするため、どうしたって汎用性を狙うことになる（なっている）と思う。

結果として、重すぎたり、あるいは痒いところを放置されたり、うるさかったり、役に立たなかったり、かえって作業負荷が増えてしまったり、独自世界（いや、提供者とその推進者はデファクトという呪文を唱えるんだろうけど）がおいでおいでしたり、いろいろなインピーダンスミスマッチ（というようにこの言葉を使うのはミスマッチでは無いと思うが実際はどうだろう？）が発見できる。

したがって、（たとえば.NET Frameworkなんて名前はフレームワークだが、環境一式なわけだからおいておくとして）、Strutsみたいな本当に何もしてくれないフレームワークが重宝するのだ、と思う。

何もしてくれないのは、もちろん、ビジネスのドメインに対してだ。リクエストの振り分けのような全体の制御構造の提供とか、タグライブラリのような便利コンポーネントの提供とかはしてくれている。

逆に使い物にならない典型例がcommons-loggingで(どこにもフレームワークとは書いていないが、Collectionフレームワークみたいな使い方をする場合のフレームワークではあると考えるのでそう呼ぶ)、それはなぜかといえば想定している情報量が、レベル、メッセージ、スローアブルの3種類だけだからだ。って言うか、こっちの勘違いなのかも知れないが。でも少なくこっちが想定するログというのは1つのログに時刻みたいなもの以外に5から6個ぐらいの要素があるしな。org.apache.commons.logging.Logインターフェイス以外にも引数として10要素くらい取るものがあるのかな？

で、無いと仮定して続けるとこれは、J2SEのLoggerについても言えることだが、結局、不足しているものをごまかすためにはメッセージを書式化して工夫するくらいしか手が無いことになる。たとえばCSVとするとか。でもそんな文字列の書式を定義するくらいなら、独自ロギングフレームワークにしてしまったほうが得（APIの学習性、コンパイル時型チェックの可能性、メンテナンス性、サポート用ソース量、将来性＝ログはプログラミング言語に依存せず、製品に依存し、製品の構築は異なるプログラミング言語でも良く、しかもログは場合によっては30年後にだって読めなければならなかったりとか）なのだ。

これは実はおもしろい。ログなんてのは非機能要件だったりするからフレームワークを使って楽ができるとかデファクトで良いでしょうとか思えるにもかかわらず（実際、w/o EJBのようにそんなことを書いている本もある）、その実、全くそうはならないからだ。非機能要件だからこそ逆に既存アーキテクチャに強く依存していたりするのだ。逆に機能要件に深くかかわりかねないWebアプリケーションフレームワークのほうが容易にフレームワークを交換可能だったりする。っていうか、僕が想定しているログと世間のログが異なる可能性もあるけど。

機能要件にかかわっているにもかかわらず、このタイプのフレームワークが交換可能なのは、開発対象に入り込まないか、あるいは入り込んでも薄い層の部分ですむからだ。それは呼び出し側だからということもできる。アプリケーションは（StrutsであればActionFormとタグライブラリを除いて。といってもタグライブラリはStrutsのフレームワークそのものとは実際には独立して利用できるからちょっと別に考えた方が良いかも知れない）呼ばれるだけ（IoCですね）なので、呼び出し側が変わってもほとんど影響がない（Actionであれば、ActionFormという引数について影響が出るけど、容易に代替可能だし、ビジネスドメインはまったく影響されない）ということだ。

で、なんでそんなことを思ったかというと、結局、『何でもかんでも１つのフレームワーク自身にしてほしいわけではなくて、便利な機能をもったコンポーネント群をインタフェース経由でマネージメントだけをしてくれるだけのフレームワーク』っていうのはその通りだなと感じたからだったりする。で、そのコンポーネント群の中にこちらのアプリケーションも含めることができればそれで良いのだ。

Loggingは、下に複数のロガー実装を許すための便利なフレームワークに見えるけど上の理由から、まったく使い物にならない。それよりは直接オレサマロガーのAPIを公開して使わせた方がよろしい。しかし、モデルにそんなものは埋め込みたくはない(もっともオレサマアプリケーションであれば全然問題にならないのは、オレサマロガーは製品全体を通して利用される以上、当然バッチ的な実行ー当然ユニットテストはこの領域となる―もサポートしているからなのだが)。ならばそういう依存性がある部分はAOPで外に追い出せば良いかも知れない。

コード―フレームワーク―物理実装

ではなく、

コード　← コードー物理実装

なのだ。

で、そういうことを考えて行くと、J2SEとか.NET Frameworkのような環境そのもののフレームワークと、Strutsのような層間インターフェイスを実装したフレームワーク以外は、オレサマのほうが結局、使い心地も良く、メンテナンス性も良いのだ（だって、汎用をはなから考えていないから機能が少なくて済み、その結果コードも少なくバグもゼロ化可能だ（すべてのパターンを網羅したテストが可能となる）。拡張も自由だし）。

#視点が一定していないし、主張が交錯している。下書き未満ということで。