(4) 编译新增的具体日志记录器类和具体日志记录器工厂类,运行客户端测试类即可使用新的日志记录方式,而原有类库代码无须做任何修改,完全符合"开闭原则"。

通过上述重构可以使得系统更加灵活,由于很多设计模式都关注系统的可扩展性和灵活性,因此都定义了抽象层,在抽象层中声明业务方法,而将业务方法的实现放在实现层中。

有人说:可以在客户端代码中直接通过反射机制来生成产品对象,在定义产品对象时使用抽象类型,同样可以确保系统的灵活性和可扩展性,增加新的具体产品类无须修改源代码,只需要将其作为抽象产品类的子类再修改配置文件即可,根本不需要抽象工厂类和具体工厂类。

试思考这种做法的可行性?如果可行,这种做法是否存在问题?为什么?

工厂的作用除了将对象的创建和对象的使用分离之外,还有一个作用就是可以屏蔽一些对象初始化的工作,如果直接反射得到具体产品对象,那么反射之后,需要每次做初始化工作,而工厂中就直接初始化完成了。反射生成对象只能适用一些最简单的情况,如果对象的创建比较复杂,例如要调用有参的构造函数,创建之前需要配置相应的环境,则需要将这些代码封装到工厂中,而工厂的作用不仅仅是简单的创建一个对象。