機能を追加する：サブクラスとデコレータ

Question

現在、プレゼンテーション層にOracleのADF Faces JSF実装を使用しているレガシーシステムで作業しています。システムは、ルールエンジンを使用して、ユーザーとのやりとりや入力された値に応じて、必要なフォーム要素、必要不可欠な要素、または強調表示さえするようにします。

現在のところ、アプリケーションは「作業中」です。ルールエンジンとフロントエンドの更新を扱う現在の実装では、非常にエレガントではありませんし、次のようなif文の大規模なセットで構成されています

if(screenObj instanceof CoreInputText) { 
    ((CoreInputText) screenObj).setDisabled(true); 
} 

は、我々はまた、その中で混合し、私たち自身のオブジェクトを持ってミックスを複雑にするには全体として設定するような何かをやって私たちの選択肢を排除するため、共通の祖先を共有しない：

((CommonAncestor) screenObj).setDisabled(true); 

問題は、それがクリーンでより明確にするために、コードのこの部分を作り直し価値があるだろうかどうかではありません。画面要素の大部分はADF Faces要素なので、追加のメソッドを追加するために祖先を変更することはできません。

コード変更の目標は、古いコードをクリーンアップし、新しい要素やコントロールを追加しても大きなコード変更（特に存在するifステートメント数多くの場所で）。

私たちが探しているものを達成するためのよりよい選択であるこの変更を進めたら、すべての要素をサブクラス化する（既存の別のコントロールを利用するたびに新しいクラスが必要）か、デコレータパターンを実装するか？デコレータの私の唯一の懸念は、各追加要素に対してコード変更が必要であることです。両方のオプションは、これらのifブロックを含む複数のメソッドが更新する必要がないため、コードの変更を減らすように見えます。

サブクラス化やデコレータ以外のこのような状況を処理するメソッドの入力はすべて歓迎です！

Answer 1

共通の祖先はありませんが、共通の方法があるかどうかは指定しません。もしそうであれば、ただ一つの共通の型を持つように、メソッドを呼び出すだけのプロキシを使って、実行時にインタフェースに入れてください。これは一種のデコレータですが、リフレクションを使用するので遅すぎる可能性はありますが、正しいメソッドシグネチャを実装するだけの新しいオブジェクトの利点があります。古いオブジェクトのプロキシを予約し、オブジェクトがそれを必要とするかどうかをチェックするファクトリメソッドで条件付きでプロキシを作成します）。

また、これが真のセッターであれば、ApacheのBeanUtilsを使用して、disabledというプロパティーとして設定することもできます。

EDIT：同じメソッドを持たないことを考えると、新しいオブジェクトを追加するたびに新しいコードに追加する必要があるコードがあります。 。つまり、もしあなたがリフレクションルートを辿ることができたら、メソッドへのクラスのマップを作成することができます（メソッドがすべてブール値をとるならば、それを回避することもできます）地図上に表示されます。そうすれば、新しいオブジェクトを導入するときに、マップにエントリを追加するだけで済みます。

しかし、私の好みはそれがあまりにも遠すぎると思われるので、避けることです。それはメソッド名をリファクタリングするのが非常に難しくなります。そして、IDEがそれらのコンテキストで使用されていることを理解することは不可能です。私はデコレータが最初の赤面で正しい選択だと思う。他の配慮を無視して、構成は継承を優先すべきであり、何が起こっているのかを明確にし、長期的にメンテナンスを改善するからです。