Java:过度使用反射？

Question

我想知道我是否过度使用了 java 反射。
我有一个类，它是几张 map 的数据持有者。我有 public get(...) 方法，它给定一个键作为输入，在相应的映射中返回与其关联的值。
由于 map 很大，我只在我真正想要访问它们时才加载它们。因此，在每个 get(...) 方法中，我检查 map 是否为空。如果是，我调用相应的 loadMap(..) 方法。
这是一个示例代码片段

 public getId(String name)  
 {
     try
     {
     if(nameMap1 == null)
        loadNameMap1();
     } catch(...) {....}

     return nameMap1.getId(name);
 }

问题是我有多个 map 。因此，为了加载每个 map ，我有不同的 loadMap(..) 方法和 get(...) 方法中的 try catch block 。因此，我没有写一个名为 loadMap(Object map, String methodName) 的方法，它使用反射来调用适当的方法，并处理所有异常。

private synchronized void loadMap(Object map, String methodName)
{
if (map == null)
    try
    {
    Method method = this.getClass().getDeclaredMethod(methodName, new Class[0]);
    method.invoke(this, new Object[0]);
    } 
    catch (..)
}

我在这里过度使用反射了吗？有一个更好的方法吗？这是否符合 Effective Java by Joshua Bloch 中所写的“反射的有限使用”？
(旁注:我无法将类重构为多个类)

Answer 1

// could also be static
private Map<String, Callable<Map>> myLoaders;

private synchronized void loadMap(Object map, String mapName)
{
if (map == null)
    try
    {
       Callable<Map> mapLoader = myLoaders.get(mapName);
       map = mapLoader.call();
    } 
    catch (..)
}

// and in the constructor or other init code
myLoaders.put("map1", new Callable<Map>(){
     Map call(){
        // load map 1
     }});

我认为，尽管如果您所做的只是将一个通用的 try/catch 逻辑从几个需要重复的方法移动到一个地方，那么这是错误的方法。这样你就失去了很多编译器错误检查支持。有些人会为此使用像 Aspect/J 这样的工具，但我认为你只需要接受 Java 没有真正的工具来处理这个事实，通过使用共享私有(private)函数将困惑减少到最低限度，并接受这两个复制/粘贴行。只要这些行中没有“真正的代码”，就不是真正有害的代码重复。

所以:

 public getId(String name){
     try{
        if (nameMap1 == null)
            loadNameMap1();
        }
      catch (....){
          privateHelperFunctionThatCutsThisDownToOneLine(name, "id", "nameMap1");
      }
  }

  // you are left with the above repetitive three (or seven) lines,
  // but that is Java for you...
  // in return, you get nice, static compile-time error checking


 private void privateHelperFunctionThatCutsThisDownToOneLine(){
      // all the long repeated code in the exception handler
      // goes here.
 }