DisplaytagのColumnDecoratorから見るインタフェースの可変性によるユーザーへのダメージ
周知のように、Displaytagが1.0から1.1にアップグレードされた後、カラム修飾器のインタフェースが改善され、1.1以降のバージョンではColumnDecoratorは使用を推奨しておらず、DisplaytagColumnDecoratorに取って代わって、この2つのインタフェースの間の主な違いはインタフェースのdecorateメソッドが受け入れるパラメータに集中していることがわかります.この2つのインタフェースのdecorateメソッドのプロトタイプは、次のとおりです.
ColumnDecorator:String decorate(Object columnValue) throws DecoratorException;
DisplaytagColumnDecorator:Object decorate(Object columnValue, PageContext pageContext, MediaTypeEnum media) throws DecoratorException;
DisplaytagColumnDecoratorでのdecorateメソッドの戻りタイプについても,従来とは異なり主にチェーンモードをサポートするためであるが,ここでは議論しないが,パラメータの違いによるインタフェースの変更はDisplaytagの設計上の欠陥を説明していると述べたい.もし後でDisplaytagの設計者が列修飾器クラスがその仕事を完成する時依然として残りのパラメータが必要であることを発見したら、もう一人のDisplaytag 2 ColumnDecorator同僚を設計してDisplaytagColumnDecoratorを廃止しなければならないのではないでしょうか.これは決して危険な言葉ではない.
やはりJSRのいくつかのAPIから経験を吸収して、decorate方法のパラメータをある単独のクラスに設計したほうがいいのではないでしょうか.サーブレットやJSP仕様ではXxxContextの概念がよく見られますが、個人的には良い方法だと思います.仮に,当初DisplaytagのColumnDecoratorにおけるdecorateメソッドのプロトタイプが次のように設計されていたとする.
Object decorate(DecoratorContext _context) throws DecoratorException;
状況はもっと良くなるかもしれませんが、もちろん1.0バージョンではDecoratorContextの定義は以下のように見えます.
ColumnDecoratorのインプリメンテーションクラスは、コンテキスト環境から装飾するオブジェクトを得ることができます:Object value=context.getDecoratedValue(); 重要なのは、1.1バージョンになると、ColumnDecoratorインタフェース自体を変更することなく、直接DecoratorContextをアップグレードすることができます.この場合のDecoratorContextは次のように見えます.
これにより、1.1バージョンを使用するユーザは、このコンテキスト環境を介してPageContextまたはMediaTypeEnumを容易に取得することができるとともに、古いバージョンを使用するユーザ、すなわち古いバージョンのユーザがアップグレードする際に、既存の列装飾器の実装がある場合は、作業中にPageContextを使用したい場合は、実装するインタフェースを変更する必要はありません.DisplaytagColumnDecoratorに幽霊に会いに行かせましょう.
もちろんDecoratorContextオブジェクトにおける各属性の付与作業はフレームワーク自体で行われており,Displaytagを使用する開発者はそれを全く心配する必要はない.
The article is end.
ColumnDecorator:String decorate(Object columnValue) throws DecoratorException;
DisplaytagColumnDecorator:Object decorate(Object columnValue, PageContext pageContext, MediaTypeEnum media) throws DecoratorException;
DisplaytagColumnDecoratorでのdecorateメソッドの戻りタイプについても,従来とは異なり主にチェーンモードをサポートするためであるが,ここでは議論しないが,パラメータの違いによるインタフェースの変更はDisplaytagの設計上の欠陥を説明していると述べたい.もし後でDisplaytagの設計者が列修飾器クラスがその仕事を完成する時依然として残りのパラメータが必要であることを発見したら、もう一人のDisplaytag 2 ColumnDecorator同僚を設計してDisplaytagColumnDecoratorを廃止しなければならないのではないでしょうか.これは決して危険な言葉ではない.
やはりJSRのいくつかのAPIから経験を吸収して、decorate方法のパラメータをある単独のクラスに設計したほうがいいのではないでしょうか.サーブレットやJSP仕様ではXxxContextの概念がよく見られますが、個人的には良い方法だと思います.仮に,当初DisplaytagのColumnDecoratorにおけるdecorateメソッドのプロトタイプが次のように設計されていたとする.
Object decorate(DecoratorContext _context) throws DecoratorException;
状況はもっと良くなるかもしれませんが、もちろん1.0バージョンではDecoratorContextの定義は以下のように見えます.
public final class DecoratorContext{
private Object decoratedValue;
public Object getDecoratedValue() {
return decoratedValue;
}
public void setDecoratedValue(Object decoratedValue) {
this.decoratedValue = decoratedValue;
}
}
ColumnDecoratorのインプリメンテーションクラスは、コンテキスト環境から装飾するオブジェクトを得ることができます:Object value=context.getDecoratedValue(); 重要なのは、1.1バージョンになると、ColumnDecoratorインタフェース自体を変更することなく、直接DecoratorContextをアップグレードすることができます.この場合のDecoratorContextは次のように見えます.
public final class DecoratorContext{
private Object decoratedValue;
private PageContext pageContext;
private MediaTypeEnum media;
//Getters and Setters
……
}
これにより、1.1バージョンを使用するユーザは、このコンテキスト環境を介してPageContextまたはMediaTypeEnumを容易に取得することができるとともに、古いバージョンを使用するユーザ、すなわち古いバージョンのユーザがアップグレードする際に、既存の列装飾器の実装がある場合は、作業中にPageContextを使用したい場合は、実装するインタフェースを変更する必要はありません.DisplaytagColumnDecoratorに幽霊に会いに行かせましょう.
もちろんDecoratorContextオブジェクトにおける各属性の付与作業はフレームワーク自体で行われており,Displaytagを使用する開発者はそれを全く心配する必要はない.
The article is end.