1700457456
}
1700457457
1700457458
}
1700457459
1700457460
场景类的调用方法如代码清单8-12所示。
1700457461
1700457462
代码清单8-12 场景类
1700457463
1700457464
public class Client{
1700457465
1700457466
public static void main（String[]args）{
1700457467
1700457468
Creator creator=new ConcreteCreator（）；
1700457469
1700457470
Product product=creator.createProduct（ConcreteProduct1.class）；
1700457471
1700457472
/*
1700457473
1700457474
*继续业务处理
1700457475
1700457476
*/
1700457477
1700457478
}
1700457479
1700457480
}
1700457481
1700457482
该通用代码是一个比较实用、易扩展的框架，读者可以根据实际项目需要进行扩展。
1700457483
1700457484
1700457485
1700457486
1700457488
设计模式之禅 8.3 工厂方法模式的应用
1700457489
1700457490
8.3.1 工厂方法模式的优点
1700457491
1700457492
首先，良好的封装性，代码结构清晰。一个对象创建是有条件约束的，如一个调用者需要一个具体的产品对象，只要知道这个产品的类名（或约束字符串）就可以了，不用知道创建对象的艰辛过程，降低模块间的耦合。
1700457493
1700457494
其次，工厂方法模式的扩展性非常优秀。在增加产品类的情况下，只要适当地修改具体的工厂类或扩展一个工厂类，就可以完成“拥抱变化”。例如在我们的例子中，需要增加一个棕色人种，则只需要增加一个BrownHuman类，工厂类不用任何修改就可完成系统扩展。
1700457495
1700457496
再次，屏蔽产品类。这一特点非常重要，产品类的实现如何变化，调用者都不需要关心，它只需要关心产品的接口，只要接口保持不变，系统中的上层模块就不要发生变化。因为产品类的实例化工作是由工厂类负责的，一个产品对象具体由哪一个产品生成是由工厂类决定的。在数据库开发中，大家应该能够深刻体会到工厂方法模式的好处：如果使用JDBC连接数据库，数据库从MySQL切换到Oracle，需要改动的地方就是切换一下驱动名称（前提条件是SQL语句是标准语句），其他的都不需要修改，这是工厂方法模式灵活性的一个直接案例。
1700457497
1700457498
最后，工厂方法模式是典型的解耦框架。高层模块值需要知道产品的抽象类，其他的实现类都不用关心，符合迪米特法则，我不需要的就不要去交流；也符合依赖倒置原则，只依赖产品类的抽象；当然也符合里氏替换原则，使用产品子类替换产品父类，没问题！
1700457499
1700457500
1700457501
1700457502
1700457503
设计模式之禅 8.3.2 工厂方法模式的使用场景
1700457504
1700457505
首先，工厂方法模式是new一个对象的替代品，所以在所有需要生成对象的地方都可以使用，但是需要慎重地考虑是否要增加一个工厂类进行管理，增加代码的复杂度。
[
上一页 ]
[ :1.700457456e+09 ]
[
下一页 ]