new的问题
----new实现依赖,不能应对具体实例化类型的变化

面向接口编成-----依赖借口,而非依赖实现

动机:
  在软件系统中,经常面临着“一系列相互依赖的对象”的创建工作;同时,由于需求的变化,往往存在更多系列对象的创建工作。
  如何应对这种变化?如何绕过常规的对象创建方法(new),提供一种“封装机制”来避免客房程序和这种“多系列具体对象创建工作”的支耦合?

意图:
  提供一个接口,让该接口负责创建一系列“相关或者相互依赖的对象”,无需指定它们具体的类。
  出自:《设计模式》GoF

Abstract Factory模式的几个要点:
  1、如果没有应对“多系列对象构建”的需求变化,则没有必要使用Abstract Factroy模式,这里使用简单的静态工厂完全可以。
  2、“系列对象”指的是这些对象之间有相互依赖、或作用的关系,例如游戏开发场景中的“道路”与“房屋”的依赖,“道路”与“地道”的依赖。
  3、Abstract Factory模式主要在于应对“新系列”的需求变动。其缺点在于难以应用“新对象”的需求变动。
  4、Abstract Factory模式经常和Factory Method模式共同组合来应对“对象创建”的需求变化。

 

Abstract Factory抽象工厂(创建型模式)//道路
Abstract Factory抽象工厂(创建型模式)
public abstract class Road
}


 

相关文章:

  • 2021-08-10
  • 2021-05-22
  • 2021-09-29
  • 2021-04-13
  • 2021-09-30
  • 2021-09-02
  • 2022-12-23
  • 2022-02-23
猜你喜欢
  • 2022-12-23
  • 2021-09-19
  • 2021-12-23
  • 2021-06-14
  • 2022-03-06
  • 2022-01-06
  • 2022-12-23
相关资源
相似解决方案