利用反射机制实现工厂模式

//细节:命名规则类，接口名称都得大写;
// 写完代码记得格式化，就算是测试代码，贴出来也是给人看的。不能太水。
interface Fruit {
    //接口中的 public abstract 都是多余的声明，eclipse是发现不了的。
    //若是有心人就换编辑器，intellij idea，
    void eat();
}

class Apple implements Fruit {
    public void eat() {
        System.out.println("Apple");
    }
}

class Orange implements Fruit {
    public void eat() {
        System.out.println("Orange");
    }
}

class Factory {
    public static Fruit getInstance(String ClassName) {
        Fruit f = null;
        try {
            f = (Fruit) Class.forName(ClassName).newInstance();
        } catch (Exception e) {
            e.printStackTrace();
        }
        return f;
    }
}

class Hello {
    public static void main(String[] a) {
        Fruit f = Factory.getInstance("Reflect.Apple");
        if (f != null) {
            f.eat();
        }
    }
}

现在就算我们添加任意多个子类的时候，工厂类就不需要修改。

上面的代码虽然可以通过反射取得接口的实例，但是需要传入完整的包和类名。而且用户也无法知道一个接口有多少个可以使用的实现类

(代码是别人的，总结是自己的，就像jdk是别人的，理解是自己的一样。)

不足之处:商品多的话，会出现海量的商品类，虽然在工厂中省去了具体判断是什么样的商品，但是还是免不了去做一大堆的商品类。这个常不常用我就不敢妄加断言啦。但是下面的三个规则还是存在的。只是工厂中省去了具体判断。

总结下有以下三个方面，来实现一个工厂方法。

工厂规则：

有个接口，作用是提供一个规则，估计也可以是一个抽象类，提供大部分公共方法的实现也是可以的
工厂商品：

商品的种类很多，各不相同，但是都有一个共通点，那就是都遵守上面的工厂规则。具体实现可以实现接口或者继承抽象方法等等。
工厂：

返回的是一个接口类型的商品对象，对外提供的也只是规则中包含的方法。根据商品之间的不同，来生产不同的商品。相当于父类型的引用指向其实现类或者子类，(多态)，当然，也可以类型强制转换成子类对象。就像男人是人，人不一定是男人。类似这种关系。

Apple apple = (Apple) f;

咳咳，写错了，人能不强转成男人，至于为啥就自己猜吧。

编译时没错，运行时就炸了，这个也是多态的一个常问的问题。就不赘述啦