同为创造型
设计模式的简单工厂模式
可以理解为对new关键字的代替。
本着重复三次即重构的原则,如果一个对象在不同的地方被new了两次以上,那就可以考虑使用它。那我们为什么要用简单工厂模式代替new呢?就像我们使用Getter Setter代替直接读写字段一样,说白了就是加上一个间接层,以缓冲处理流程的变化(比如获取字段的时候,为其加上100再返回,写在Getter里就不需要散弹式修改)。
相比起来工厂方法模式无疑复杂了很多。引用一句维基百科上对其用途的解释:
Deal with the problem of creating objects without having to specify the exact class of the object that will be created
也就是说用在不想直接引用精确类型来创建对象
的时候。等等,不引用精确类型那不就是多态吗,那我们直接用
AInterface a;
//TODO: 对a依赖注入
a.work();
AInterface b;
//TODO: 对b进行不同精确类型的依赖注入
b.work();
这样的形式不就行了吗?
如果这样就能解决问题,当然可以这样用,毕竟重构只在必要的时候去做。但是对a进行依赖注入的工作肯定不会自动完成,为了解决这个问题出现了一大批依赖注入框架。如果你不想用笨重的框架,那你就得自己去创建a的实例,然后理所当然的你就必须知道a的精确类型,毕竟你不能直接new一个接口,至少在java里是这样。所以你有了这样的代码:
AInterface a;
a = new AInterfaceImpl();
a.work();
AInterface b;
b = new BInterfaceImpl();
b.work();
事实上,恶心的工作不会消失不见,顶多可以把恶心的工作延迟完成,不然我们的程序不可能跑得动。在上面的需求里,你不能永远忽视a的精确类型,就算用依赖注入框架也是一样的,在程序的某个地方,你必须给它一个明确的类型。但是,程序员的美德是,复杂的工作,永远要推迟到后面去实现,至少在上面的代码里,我想要隐藏精确类型,比如像这样:
Factory factory;
//TODO: 对factory依赖注入
//看,用起来很简单对吧
AInterface a;
a = factory.getIt();
a.work();
//TODO: 对factory进行不同的依赖注入
//用多态的特性做不同的工作
AInterface b;
b = factory.getIt();
b.work();
好吧,我们解决了一个问题,然后引入了另一个问题。现在我们必须关心Factory的精确类型了。我们不停地把垃圾扔给别人,以保持自己的干净。
对于不停传递垃圾这种行为我已经累了,不想写了,但是工厂方法模式当然还没有结束,有空再写吧