抽象工厂模式学习笔记整理

new的问题

常规的对象创建方法

    Road road = new Road();

new的问题

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

解决思路

    -封装变化点:哪里变化,封装哪里
    -潜台词:如果没有变化,当然不需要额外的封装

 

工厂模式的缘起

    变化点在"对象创建",因此就封装"对象创建"

    面向接口编程:依赖接口,而非实现

    最简单的解决办法:

Code

 

简单静态工厂:创建一系列相互依赖的对象
 
    假设一个游戏开发场景:我们需要构造"道路"、"房屋"、"地道"、"丛林"等等对象。    

Code

   
    缺点:不能应对不同系列相互依赖的对象
   

动机(Motivation)

    在软件系统中,经常面临着"一系列相互依赖的对象"的创建工作;同时,由于需求的变化,往往存在更多系列对象的创建工作。

    如何应对这种变化?如何绕过常规的对象创建方法(new),提供一种"封装机制"来避免客户程序和这种"多系列具体对象创建工作"的紧耦合?

意图(Intent)

    提供一种借口,让该接口负责创建一系列"相关或相互依赖的对象昂",无需指定它们具体的类。

抽象工厂示例代码

Code

 

抽象工厂结构图

Abstract Factory模式的几个要点

    如果没有应对"多系列对象构建"的需求变化,则没有必要使用抽象工厂模式,这时候使用简单工厂完全可以。

    "系列对象"指的是这些对象之间有相互依赖、或作用的关系,例如游戏开发场景中的"道路"与"房屋"的依赖,"道路"与"地道"的依赖。

    抽象工厂模式主要在于应对"新系列"的需求变动,其缺点是难以应对"新对象"的需求变动。

    抽象工厂模式经常与工厂方法模式共同组合来应对"对象创建"的需求变动

 

 

posted @ 2009-05-10 20:35  网络渔夫  阅读(476)  评论(0编辑  收藏  举报