私は現在、宣言されたフィールドを操作することによってリフレクションを多用するクラスを設計しています。したがって、多くのメソッドには、本体に関して共通点があります。これは、(うまくいけば)次のJavaコードで示されています。
import java.lang.reflect.Field;
public class foo {
public void foo1(/* arguments1 */) {
for (Field f : getClass().getDeclaredFields()) {
// do some stuff using arguments1
}
}
public void foo2(/* arguments2 */) {
for (Field f : getClass().getDeclaredFields()) {
// do some stuff using arguments2
}
}
public void foo3(/* arguments3 */) {
for (Field f : getClass().getDeclaredFields()) {
// do some stuff using arguments3
}
}
//and so on...
}
このクラスに最終的に含まれるメソッドの数によっては、これは設計上の欠陥と見なすことができますか?getFields()
たとえばの代わりに使用したい場合はgetDeclaredFields()
、出現するすべてのを置き換える必要がありgetDeclaredFields()
ます。これは私には良いプログラミングの練習のようには思えません。私の場合、これはあまり現実的なシナリオではないかもしれませんが、興味を引くために、この問題に取り組むデザインパターンやコンセプトがあるかどうかを知りたいと思います。
[編集]
追加の誤解を避けるために:ループ内の操作はfoo1、foo2などによって与えられた引数に依存し、それらの引数は各メソッドで常に同じであるとは限りません。私はこの事実をうまく説明しませんでした。私はそれをよりよく示すために与えられたコードを改善しました。