工厂的争议

工厂的争议

说起设计模式，你第一个所想到的几个设计模式里，一定有工厂模式。因为它既简单方便，见效快。但像所有设计模式一样，它也有着争议。

============================

工厂的滥用

第一次明确的学习接触工厂模式，是在大学里学习JavaEE开发。老师的示例代码里，分别给Business，Dao设置了工厂，用来创建Business,Dao。

就像这样：

class BusinessFactory{

    public static IUserBusiness getUserBusiness(){
        return new UserBusinrss();
    }

    public static IStudentBusiness getStudentBusiness(){
        return new StudentBusiness();
    }

}

class DaoFactory{
    public static IUserDao getStudentDao(){
        return new UserDao();
    }

    public static IStudentDao getStudentDao(){
        return new StudentDao();
    }
}

老师说：这样的好处就是，将来你有更改实现类的时候，就不需要跑到每个地方去改new的地方了。

当时觉得好有道理啊！设计出这个模式的人怎么这么聪明啊！！！

恩……年轻真好。

来让我们吐槽这个事情吧。

首先，必须要承认工厂减少new关键字，避免多处修改的好处，这是开闭原则的非常好的一个体现。多处且大量new一个对象时，可以使用工厂模式

然后我们就从实际吐槽：

• 就我们那小项目，一个getUserBusiness的调用次数绝对没超过3次。（大部分时候只有一次）

  在通常只作为一对一调用的对象上画蛇添足的增加工厂方法，是非常愚蠢和增加工作量的行为。

• 可见的未来完全没有扩展的需求和欲望and必要。

  完美的开闭原则体现在于，功能的扩展与修改，不去改变原有类，而是继承现有类进行重写，并修改实现。但是这条原则的使用率并不高。做第三方外部依赖库时有这样做的需求，但大部分我们这些开发业务需求的开发者来说，这样不但没有好处，反而造成代码冗余与垃圾沉淀。扩展一个类远没有直接去修改的方便。

  （想象一下，你能接受你的项目里有大量不被使用的年久垃圾代码？）

• 要是哪天我的构造方法突然增了一个参数咋办？我不是要去调用出修改吗？

  醒醒吧，你要加参数。你的参数谁给你传？不还是要通过工厂方法的接口吗？还不是要去每个地方修改？如果不是，那就是不需要传递的参数，那不能直接去类里面增加？（当然我们不排除真有这样的特殊情况）

那么，现在你明白了为什么不要滥用工厂了吗？没有正确的方案，只有合适的方案。好用的东西不要滥用。