かつのりの日記２

フレームワークのデザイン

もうそろそろ、まともなプロダクトを一つ作りたいと思っているのですが、候補としてDIコンテナやORマッパー等を考えていますが、まずはDIコンテナを作りたいなと思っているところです。そこで自分なりのフレームワーク構築の為のガイドラインについてまとめてみようと思います。

まずフレームワークを構築する為にはデザインが必要となりますが、フレームワークをデザインするときは、ボトムアップ的なアプローチが必要になります。ボトムアップ的なアプローチを無視すると、フレームワークを利用した実装コードが非常に書きにくくなります。これはオープンソースであってもシステム開発プロジェクト専用の独自フレームワークでも同じです。

自分の場合はフレームワークを利用した仮想コードから書くようにしています。そこにはUMLやら、なんちゃらプロセスやら、小難しい概念なんて何もありません。単純にテキストエディタで仮想コードを書き連ねていけばよいのです。例えばデータベースにアクセスするフレームワークを考えるとしましょう。まずは「こんな感じで書ければ楽かな～」くらいでいいのです。フレームワークの実装なんて全く気にする必要はありません。

public class Dao<T extends Table>{ public T getTable(){ //何かする } } public class FooDao extends Dao<FooTable>{ public Foo[] getFoo(){ FooTable table = getTable(); Foo[] foo = table.findByCriteria( Criteria.column("name").eq("aaa").and().column("age").gt(100) ); return foo; } public void insert(Foo foo){ FooTable table = getTable(); table.insert(foo); } }

上記コードは全く何も考えずに書いてみました。実装なんてものはなく、こうやって書けばSQLの実行が楽じゃないかな的なアプローチです。（実際に楽か楽じゃないかの議論は別として）

これから、上記コードが有効となるようなフレームワークを構築すれば、自然と楽なコードで実装が可能なフレームワークが出来上がるわけです。実際には最低限の汎用性や拡張性を考える必要もあり簡単ではありませんが、まずトップダウン的な要求を無視して実装してみる事です。

トップダウン的な要求の通りに実装すると、「あれもできた方がいいんじゃね？」みたいな意見に押しつぶされて、本当に使うか分からない機能の為に、無意味に汎用化されたフレームワークが出来上がることが多いです。無意味に汎用化されたフレームワークは、標準の方法と手続き方法が違うだけであったり、コードを書くのと何ら変わらないボリュームの設定ファイルが必要になったりします。

ちなみに今実装したいなと考えているのはDIコンテナです。

public class FooConfiguration implements Configuration{ public void configure(Context context){ context.register(Foo.class); context.register(Bar.class).initializer(AutoSetter.class); context.register(Buz.class).creator(new Creator(){ public Buz create(){ return new BuzImpl(); } }.getClass()); context.register(HogeService.class.getPackage(),new InterfaceFilter()); context.include(BarConfiguration.class); context.aspect(FooInterceptor.class).target(new XXXTarget()); } }

こんなコードで設定を書いて、

public class Test{ public static void main(String[] args){ Container container = ContainerFactory.getContainer(FooConfiguration.class); } }

というようにコンテナが取得できれば楽かなと思って実装していこうと考えています。

投稿日時 : 2007年8月27日 1:58