Woolpack の特徴の詳細。
  Woolpack の特徴の詳細を以下に示す。

  特徴 | 理由 | 利点 | 概念上・実装上の欠点 | 該当モジュール
  --- | --- | --- | --- | ---
  インタープリタ デザインパターンを適用する。 | interpreter.htmlの特徴を参照。 | interpreter.htmlの特徴を参照。 | interpreter.htmlの注意点と考慮点を参照。 | config / dom / el / el.converter / html / text / utils / utils.concurrent / validator の各パッケージ
  フレームワークで設定ファイルを仕様化しない。特に XML を使用しない。 | 設定ファイルを重量化する場合、柔軟性を確保するスキーマ設計と XML をインスタンスツリーに変換する設計の難易度が高い。シリアル化(サーバ間で設定を通信するなど)を必要としない。 | ユーザが設定を制御することが容易。 設定ファイル専用エディタが不要。 Java の場合は全ての機能が Java の API として表現されてるため、API のリファレンスが Javadoc のみである (設定ファイルのリファレンスやタグライブラリのリファレンスが不要)。 | Java 言語は new 宣言の引数に変数名を付けることができないため可読性が悪い。動作定義の動的変更機能を具備しない。 ユーザのソースコードに文字列が直接指定する記述になるため、文字列を ResourceBundle 化するなど一部のコーディング規約を遵守することができない(遵守すると可読性が低下する)。 Java は静的型の言語であるため、型宣言の記述が多くなる。 | API 全体
  HTML 雛型と値の注入処理を分離する。 | Mayaa にインスパイアされた。 | 値の注入処理を共通化することが可能。それにより画面生成処理の手間を削減することが可能。 | 特定の HTML 雛型に固有の処理を記述する柔軟性を確保する設計の難易度が高い。 | dom / html の各パッケージ
  HTML・値検証・モデル間でプロパティ名をキーとして値を自動バインドする。 | 利点に同じ。 | HTML・値検証・モデル間でプロパティ名を統一することにより、個別に値をバインドする定義が不要になる。 | 識別子の値を個別に変換してバインドする仕掛けを用意していない。 | woolpack.validator パッケージ, AutoUpdate, ActionInvoker
  Struts の Tiles に相当する機能として HTML フレームを HTML テーブルに変換する機能を具備する。 | 利点に同じ。 | HTML で作成したレイアウトをそのまま利用することができる。 | target 属性値の判定機能を具備しない。コンストラクタツリーで作用対象の HTML を指定する必要がある。XHTML に対応していない。 | Frame2Table
  コンテキスト役へのアクセスに動的型定義言語を利用することが可能。 | 利点に同じ。 | フレームワークと POJO の結合を疎に保ちながらフレームワークから POJO の手続きを呼び出すことができる。 | 動的型定義言語を Java ソースの String 値として定義するため、バックスラッシュなどエスケープ文字の可読性が悪い。 | API 全体

  Woolpack の実装上の特徴の詳細を以下に示す。

  特徴 | 理由 | 利点 | 概念上・実装上の欠点 | 該当モジュール
  --- | --- | --- | --- | ---
  Context 役の各プロパティを J2SE の API に限定している。 | 利点に同じ。 | JUnit によるテストが容易。フレームワーク設計の抽象化が維持される。Servlet API に依存する部品が局所化される。 | クライアント情報(Locale や OS/ブラウザ名など)による処理の分岐をするためにはコレクションフレームワークを媒介するか ThreadLocal を使用する必要がある。 | DomContext
  Java 言語の final キーワードを多用する。 | イミュータブルが静的に検証される。 | 動点固定法の効果により設計のアイデアが創発される。イミュータブルの見える化が維持される。クロージャ(インタフェースによる擬似的なもの)を使用することが可能。 | 動的に設定を更新することができない。参照型変数のコピーをとる実装を行っていない。 | API 全体
  Generics を多用する。 | 利点に同じ。 | ソースの可読性が維持される。 | 1.4 以前の JSE に対応していない。 | API 全体
  dom / html の各パッケージのクラス名が名詞になっていない。 | Expression 役が LISP の関数と対応づけられる、また Expression 役は文法規則を表すことが多いため、名詞にする効果が弱いと判断した。 | コンストラクタツリーが読みやすい。 | 一般的なクラス名の命名規則に従っていない。 | dom / html の各パッケージ
  Woolpack が利用するライブラリで発生した RuntimeException のサブクラスでない例外は全て JSE の RuntimeException のサブクラスでラップして投げる。 | なるだけ JDK 標準パッケージの例外クラスを利用することがコーディング規約で推奨されている(注1)。 | 検査例外／チェック例外 (checked exception) の宣言が不要なので、部品の設計が単純化される。 | 呼び出し元で Throwable#getCause() を解析する必要がある。 interpreter パターンではインタフェースに対する実装のバリエーションを インタフェース設計時に想定するのが難しいため、 投げる可能性のある JDK 標準パッケージの検査例外 の全てをインタフェースで宣言するのは難しい。 例外発生時の処理が暗黙化されるためバグの発見が遅れるリスクがある。 | API 全体
  Context　役に　Prototype　デザインパターンを適用することにより、変数スコープを表現している。 | Expression　役のコンストラクタツリーで変数スコープを実現する。 | Expression　役の作用範囲を制御することができる。 | 言語の変数スコープ程の柔軟性を持たない。 | DomContext, ConfigContext, ValidatorContext
  フレームワーク自体は正常時にログを出力しない。 | エラー発生時に Context 役のダンプを出力する様にして正常時のログ出力を抑えている。 djUnit でフレームワークの動作検証を行うため、ログによるフレームワークの動作検証は不要と判断した。 | 部品の設計が単純化される。ログ出力の処理時間を節約することができる。 | デバッグ用のデータが不足する可能性がある。 | API　全体

  注1：http://www.objectclub.jp/community/codingstandard/を参照。

トップに戻る
Copyright (C) 2006 Takahiro Nakamura. All rights reserved.