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

多くの場合、リフレクションは肥大化したコードまたは誤って設計された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> { }
      
      





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



All Articles