设计模式学习草书

1.问题的提出。。。。 

new的问题。

常规的对象创建方法：

第一种方法：

Road road = new Road();

new 的问题：

实现依赖，不能应对“具体实例化类型”的变化。

解决思路：

封装变化点----哪里变化，封装哪里。

如果没有变化，当然不需要封装了。

  

工厂模式的缘起：

变化点在“对象创建”，因此就封装“对象创建”

面向接口编程-----依赖接口，而非依赖实现。

第二种方法：

Class RoadFactory{

public static Road CreateRoad(){

return new Road();

}

}

客户端：

Road road = RoadFactory.CreateRoad();

 

新的需求：

如果想把return new Road()换成返回不同的路 例如：return new WaterRoad();

 

假设一游戏开发的场景：

需要构造：“道路”，“房屋”，“地道”，“丛林"等。。。

互相之间有交互。。。例如在房屋，丛林里安装地道，道路。

一系列对象之间的依赖。

第三种方法：

//相对稳定。。

Road road = RoadFactoy.CreateRoad();

Building building = RoadFactory.CreateBuilding();

 

//有可能是变化点。。

Class RoadFactory{

public static Road CreateRoad(){

return new Road();

}

public static Road CreateBuilding(){

return new Building();

}

public static Road CreateTunnel(){

return new Tunnel();

}

public static Road CreateJungle(){

return new Jungle();

}

}纯静态的实现方法。

简单工厂的问题：

不能应对“不同系列对象”的变化，比如有不同风格的游戏场景。。。

需要更改上面的变化点。。。

 

如何解决：

使用面向对象的技术来“封装”变化点。。。。。

 

有需求的变化一步步演化出。。。。。

 

动机：

“一系列相互依赖的对象”的创建工作。。。。由于需求的变化，往往存在更多系列对象的创建工作。。。

上例中如果就一个系列，那么就不需要改变了。。。

 

如何应对这种变化？？？

如何绕过常规的对象创建方法（new），提供一种封装机制来避免客户程序和这种“多系列具体对象创建工作”的紧耦合。

紧耦合：

意图：提供一个接口，让该接口负责创建一系列“相关或者相互依赖的对象”无需指定它们的具体的类。。。。

 

 

要点：

１.没有“多系列对象构建”的需求变化。则可使用简单的静态工厂。。使用的恰当。

２.“系列对象”指的是这些对象之间有相互依赖，或作用的关系。如游戏开发场景中的“道路”与“房屋”的依赖。

３.主要在于应对“新系列”的需求变动。。其缺点 在于难于应对“新对象”的需求变动。。增加AbstractProduct时，不能使用。。

4.Abstract Factory 和Factory Method模式共同组合来应对“对像的创建”。