设计模式学习总结.docxVIP

抽象工厂者模式 类图结构 优点： 封装性，每个产品的实现类不是高层模块关心的，它只关心接口、抽象表示，它不关心对象是如何被创建出来的，对象的创建是由工厂类负责的，因此只要知道该产品的工厂类是谁，就能够创建出一个需要的对象，省时省力； 产品族内的约束为非公开状态。产品族内的约束条件对调用工厂类的高层模块来说是透明的，它不需要知道其中的约束，它只关心具体的产品就可以，产品族内的约束实在工厂内实现的。 缺点： 抽象工厂最大的缺点就是产品族扩展非常困难。以上述类图为例，如果要增加一个产品C，即产品族由原来的2个增加到3个，这时我们就要将抽象类AbstractCreator增加一个方法createProductC(),然后两个实现类都要修改，这就违反了开闭原则，而且抽象类和接口是一个契约，改变契约，所有与契约相关的代码都要修改，那么这段代码就成了有毒代码，会对整个程序带来危害。 实现要点： 在抽象工厂模式中，选用哪种产品族的问题，需要采用工厂方法或简单工厂模式来配合解决。 抽象工厂模式和工厂方法模式一样，都把对象的创建延迟到了他的子类中。 具体的工厂类可以设计成单例类，他只向外界提供自己唯一的实例。 与其他工厂模式的联系和异同： 抽象工厂模式中的具体工厂负责生产一个产品族的产品。而产品族的增加只需要增加与其对应的具体工厂。 3种工厂模式都是创建型模式，都是创建对象的，但都把产品具体创建的过程给隐藏了。 工厂方法模式是针对一种产品结构，而抽象工厂模式是针对多种产品结构。 适用性： 在以下情况下应当考虑使用抽象工厂模式： 一个系统不应当依赖于产品类实例如何被创建、组合和表达的细节，这对于所有形态的工厂模式都是重要的。 这个系统有多于一个的产品族，而系统只消费其中某一产品族。 同属于同一个产品族的产品是在一起使用的，这一约束必须在系统的设计中体现出来。 系统提供一个产品类的库，所有的产品以同样的接口出现，从而使客户端不依赖于实现。 注意事项： 抽象工厂模式对产品族扩展比较困难，但是对产品等级的扩展时很容易的，即横向扩展容易，纵向扩展困难。 最佳实践： 抽象工厂模式是一个简单的模式，使用场景非常多，在软件开发过程中，涉及不同操作系统的时候，都可以考虑抽象工厂模式。例如一个应用需要在三个不同平台（windows、linux、android）上运行，不需要涉及三套不同的应用，通过抽象工厂模式屏蔽掉操作系统对应用的影响。三个不同操作系统上的软件功能、应用逻辑、UI都是非常类似的，唯一不同的是调用不同的工厂方法，由不同的产品类去处理与操作系统交互的信息。 建造者模式 类图结构： 1．建造者（Builder）角色：给出一个抽象接口，以规范产品对象的各个组成成分的建造。模式中直接创建产品对象的是具体建造者（Concrete?Builder）角色。具体建造者类必须实现这个接口所要求的方法：一个是建造方法，另一个是结果返还方法。 2．具体建造者（Concrete?Builder）角色：担任这个角色的是于应用程序紧密相关的类，它们在应用程序调用下创建产品实例。这个角色主要完成的任务包括：实现Builder角色提供的接口，一步一步完成创建产品实例的过程。在建造过程完成后，提供产品的实例。 3．导演（Director）：担任这个角色的类调用具体建造者角色以创建产品对象。导演者并没有产品类的具体知识，真正拥有产品类的具体知识的是具体建造者对象。 4．产品（Product）角色：产品便是建造中的复杂对象。指导者角色是于客户端打交道的角色。导演者角色将客户端创建产品的请求划分为对各个零件的建造请求，再将这些请求委派给具体建造者角色。具体建造者角色是做具体建造工作的，但却不为客户端所知。 优点： 封装性。使用建造者模式可以使客户端不必知道产品内部组成的细节； 建造者独立，容易扩展 便于控制细节风险。由于具体的建造者是独立的，因此可以对建造过程逐步细化，而不对其他的模块产生任何影响。 实现要点： 1．建造者模式主要用于“分步骤构建一个复杂的对象”，在这其中“每个步骤”是一个稳定的算法，而复杂对象的各个步骤之间则经常变化。 2．上一篇所说的抽象工厂模式解决“系列对象”的需求变化，而建造者模式解决单个对象里“对象部分”的需求变化。 产品不需要抽象类，特别是由于创建对象的算法复杂而导致使用此模式的情况下或者此模式应用于产品的生成过程，其最终结果可能差异很大，不大可能提炼出一个抽象产品类。 3．创建者中的创建子部件的接口方法不是抽象方法而是空方法，不进行任何操作，具体的创建者只需要覆盖需要的方法就可以，但是这也不是绝对的，特别是类似文本转换这种情况下，缺省的方法将输入原封不动的输出是合理的缺省操作。 适用性： 以下情况应当使用建造者模式： 1、相同的方法，不同的执行