テストだけでなく、リフレクションの使用について

多くの場合、リフレクションは肥大化したコードまたは誤って設計されたAPIに関連付けられています。
猫の下には、反射の肯定的な側面を示す有用な例がいくつかあります。


アヒルの選別について訓練します。

public interface ISort { int[] sort(int[] ints); } public class MergeSort implements ISort { //   } public class QuickSort implements ISort { //   } 

すぐに多くの種類の研究をしたい状況を想像してください。それらすべてが機能し、テストされることを望みます。

しかし、私たちはすべてのアルゴリズムのテストを書くのが面倒です。 したがって、ISortインターフェイスのみをテストし、他のすべてのクラスは、まるで自分自身でテストされるかのようにテストします）

 //      public abstract class ISortTest<T extends ISort> { private Class<T> aClass; private T sortAlgorithm; public ISortTest() { //       aClass = Optional.of(getClass()) .map(Class::getGenericSuperclass) .filter(el -> el instanceof ParameterizedType) .map( el -> (ParameterizedType) el) .filter(el -> el.getActualTypeArguments().length > 0) .map(el -> el.getActualTypeArguments()[0]) .filter(el -> el instanceof Class) .map(el -> (Class<T>) el) .orElse(null); } @BeforeEach void init() throws IllegalAccessException, InstantiationException { //     sortAlgorithm = aClass.newInstance(); } @Test void sortTest() { assertNotNull(sortAlgorithm); int n = 10000; int[] ints = new Random().ints().limit(n).toArray(); int[] sortInts = Arrays.stream(ints) .sorted() .toArray(); int[] testSotrInts = sortAlgorithm.sort(ints); assertArrayEquals(sortInts, testSotrInts); } } 

さて、これで怠nowの勝利を公式に発表できます。

並べ替えテストは、このようなクラスの作成に削減されます

 class MergeSortTest extends ISortTest<MergeSort> { //    } class QuickSortTest extends ISortTest<QuickSort> { //    } 

同様のアプローチが、たとえばSpring Dataで使用されています。

 public interface TestRepository extends CrudRepository<MyEntity, Long> { } 

また、私たちが知らない他の場所でも。