今、担当している Java Swing 案件のフレームワークは、ある意味すごい。○○Frame や、○○Button （○○は会社名略称）のように、Swing の全てのコンポーネントを、ラップしている。また、Swing にとどまらず、○○List や ○○Map 等の、コレクションフレームワークラッパーまである。ありとあらゆる標準 API をラップしているのだ。
ただ、自分は、以下の理由で、このフレームワークはダメだと感じる。
- 学習のコスト
- 費用対効果
ラッパーの作成は、継承または委譲で実装されているが、委譲に関しては面倒だったのか、全てのメソッド、フィールドが委譲されてないケースがあった。これでは、Java 標準 API に精通した熟練者であろうと、このフレームワークを使用する場合には、新たな学習をする必要がある。さらに、学習をしても、企業や部署が変わると、使用できないので、モチベーションが上がりにくい。
また、このフレームワークは、かなり多くのクラスをラップしているので、フレームワーク自体の開発コストは、そうとうなものだったと思われる。しかし、それだけの苦労に相当する効果が出ているかというと、とても、そうは感じられない。膨大なクラスのフレームワークは、学習するだけで膨大なコストがかかり、初めて使用した際は、工数が膨れ上がる。では、2回目以降の開発では、楽が出来るのかというと、JDKのバージョンも、そろそろ上げないといけないし、これからの案件では、このフレームワークは使われないという。
Effective Java 等の書籍を読めば分かるように、標準 APIというのは、非常に洗練されている。Jakarta Commons のように、大規模な開発を行い、さらにオープンにして、あらゆる企業で使用可能とするならともかく、一介の技術者が、その全てを改良してやろうと考えるのは、傲慢ではないだろうか。
一般開発者にとって優しいフレームワークとは、独自の作りこみを減らし、標準 API を積極的に利用して作成されたものなのだろう。フレームワーク開発者は、フレームワークを作って、一般開発者をそれに従わせるより、標準 API を利用してもらうための、Java レクチャードキュメントを用意するべきだ。
フレームワークという言葉には、ある種、華があるが、フレームワーク開発者という立場から一歩視点を広げ、ソフトウェア基盤技術者として、一般開発者の作業を楽にする方法を真摯に考えていくことが重要なのではないだろうか。