java - 使工厂方法更具动态性

Question

我正在我的代码中实现工厂模式，所以在工厂中遇到一件有趣的事情，我可以用反射替换工厂方法中的 if else 条件，使我的代码更加动态。

下面是两种设计的代码......

1) if-else 条件

   public static Pizza createPizza(String type) {

        Pizza pizza = null;

            if(type.equals(PizzaType.Cheese))
            {
                pizza = new CheesePizza();
            }

            else if (type.equals(PizzaType.Tomato))
            {
                pizza = new TomatoPizza();
            }

            else if (type.equals(PizzaType.Capsicum))
            {
                pizza = new CapsicumPizza();
            }
            else
            {
                try {
                    throw new Exception("Entered PizzaType is not Valid");
                } catch (Exception e) {
                    // TODO Auto-generated catch block
                    e.printStackTrace();
                }
            }


        return pizza;
    }

2) 有反射

    public static Pizza createPizza(String type) {

            Pizza pizza = null;

            for(PizzaType value : PizzaType.values())
            {
                if(type.equals(value.getPizzaTypeValue()))
                {
                    String fullyQualifiedclassname = value.getClassNameByPizzaType(type);

                    try {
                        pizza = (Pizza)Class.forName(fullyQualifiedclassname).newInstance();
                    } catch (InstantiationException | IllegalAccessException
                            | ClassNotFoundException e) {
                        // TODO Auto-generated catch block
                        e.printStackTrace();
                    }
                }
            }

            return pizza;
        }

第二种方式对我来说非常好，因为我可以通过使用它使我的代码更具动态性，因为我可以创建一个属性文件，其中包含与其关联的类和类型的名称，以服务于更多的打开和关闭，如如果将来所有者想要向 PizzaStore 添加更多比萨饼，那么他只需在属性文件中添加条目，然后再创建一个 Pizza 子类。

但我读到反射有很多缺点，其中很少提到。

It is hack of compiler
Automatic development tools are not able to work with reflections code
It's difficult to debug reflections code
Reflection complicates understanding and navigation in code
Significant performance penalty

非常想知道哪种设计好，因为我非常有兴趣让我的代码越来越动态。

Answer 1

您也可以在中间使用设计。例如

public interface Factory<T> {
  public T newInstance();
}

public class TomatoPizzaFactory implements Factory<TomatoPizza> {

    @Override
    public TomatoPizza newInstance() {
        return new TomatoPizza();
    }
}

public class PizzaFactory {

    private Map<String, Factory<? extends Pizza>> factories = new HashMap<String, Factory<? extends Pizza>>();

    public PizzaFactory(){
        factories.put(PizzaType.Cheese, new CheesePizzaFactory());
        factories.put(PizzaType.Tomato, new TomatoPizzaFactory());
    }

    public Pizza createPizza(String type){
        Factory<? extends Pizza> factory = factories.get(type);
        if(factory == null){
           throw new IllegalArgumentException("Unknown pizza type");
        }
        return  factory.newInstance();
    }
}

为简单的实例化实现一个 DefaultConstructorFactory。

public class DefaultConstructorFactory<T> implements Factory<T> {

    private Class<T> type;

    public DefaultConstructorFactory(Class<T> type) {
      this.type = type;
    }

    public T newInstance() {
       try {
         return type.newInstance();
       } catch (InstantiationException e) {
         throw new IllegalStateException("Can not instantiate " + type, e);
       } catch (IllegalAccessException e) {
         throw new IllegalStateException("Can not instantiate " + type, e);
    }
  }
}

But I read that reflection has many disadvantages mentioned few of them.

It is hack of compiler

这可能是一种 hack，但如果您正在编写基础架构代码，您将经常使用反射。尤其是当您编写必须在运行时内省(introspection)类的框架时，因为框架不知道它将在运行时处理的类。想想hibernate、spring、jpa等

Automatic development tools are not able to work with reflections code

没错，因为您将很多编译器问题转移到了运行时。因此，您应该像编译器一样处理反射异常并提供良好的错误消息。

在某些 IDE 中也只有很少的重构支持。因此，在更改反射代码使用的代码时必须小心。

不过，您可以编写测试来快速发现错误。

It's difficult to debug reflections code

这也是对的，因为您不能直接跳转到方法中，您必须调查变量以找出访问了哪个对象的哪个成员。 这有点间接。

Reflection complicates understanding and navigation in code

是的，如果用错了。仅当您不知道在运行时必须处理的类型(基础结构或框架代码)时才使用反射。如果您知道类型并且只想尽量减少编写的代码，请不要使用反射。如果您想尽量减少编写的代码，请选择更好的设计。

Significant performance penalty

我不这么认为。当然，反射调用是间接方法调用，因此必须执行更多代码才能实现与直接方法调用相同的效果。但这样做的开销很小。

• 如果您在工厂中使用反射代码，与所创建对象的生命周期相比，反射开销是微不足道的。
• 您的反射代码也将进行 JIT 优化。从 Java 1.4 开始，热点编译器将通过生成纯 Java 访问器来膨胀一个被反射调用超过 15 次的方法。 请参阅:https://blogs.oracle.com/buck/entry/inflation_system_properties , https://stackoverflow.com/a/7809300/974186和 https://stackoverflow.com/a/28809546/974186
• 框架使用反射并生成大量使用反射的代理，例如spring 的事务管理、jpa 等。如果它会对性能产生重大影响，那么使用这些框架的所有应用程序都会非常慢，不是吗。