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

版权声明:本文为博主原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接和本声明。
本文链接:https://lixuekai.blog.csdn.net/article/details/52256224
//细节:命名规则类,接口名称都得大写;
// 写完代码记得格式化,就算是测试代码,贴出来也是给人看的。不能太水。
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;

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

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



展开阅读全文

没有更多推荐了,返回首页