赞
踩
在现实开发中,遇到中途改需求,加功能的事情屡见不鲜.但面对已完成的程序代码,却是需要几乎重头来过的尴尬,这实在是痛苦不堪。说白了,原因就是因为我们原先所写的程序,不容易维护,灵活性差,不容易扩展,更谈不上复用,因此面对需求变化,加班加点,对程序动大手术的那种无奈也就成了非常正常的事了。所以在开发中要运用面向对象的分析设计编程思想,开始考虑通过封装、继承、多态把程序的耦合度降低,不把程序所有逻辑写在一起,尽量业务逻辑分离开,避免改动一小点东西,需要造成大量代码重新编译。这就需要使用设计模式使得程序更加的灵活,容易修改,并且易于复用。
(1)工厂类包含必要的逻辑判断,可以决定在什么时候创建哪一个产品的实例。客户端可以免除直接创建产品对象的职责
(2)客户端无需知道所创建具体产品的类名,只需知道参数即可
(3)也可以引入配置文件,在不修改客户端代码的情况下更换和添加新的具体产品类。
(1)工厂类集中了所有产品的创建逻辑,职责过重,一旦异常,整个系统将受影响
(2)使用简单工厂模式会增加系统中类的个数(引入新的工厂类),增加系统的复杂度和理解难度
(3)系统扩展困难,一旦增加新产品不得不修改工厂逻辑,在产品类型较多时,可能造成逻辑过于复杂
(4)简单工厂模式使用了static工厂方法,造成工厂角色无法形成基于继承的等级结构。
(1)工厂类负责创建对的对象比较少,因为不会造成工厂方法中的业务逻辑过于复杂
(2)客户端只知道传入工厂类的参数,对如何创建对象不关心
使用简单工厂模式,可以避免每次新增或修改一种算法的时候需要去变更原有的代码,而我们仅仅只用确定如何去实例化对象,例如输入运算符号,工厂就能实例化出对应的算法对象,通过多态就能实现计算方式。
注:每新增一种算法需要在工厂类方法中增加相应的语句,例如用switch来判断时候,就需要增加一个分支,返回新增的实例对象。
1.定义:定义一系列的算法,把它们一个个封装起来,并且使它们可相互替换。本模式使得算法可独立使用它的客户而变化。
2.适用性:许多相关的类仅仅是行为有异。“策略”提供了一种用多个行为中的一个行为来配置一个类的方法。需要使用一个算法的不同变体。例如,你可能会定义一些反映不同的空间/时间权衡的算法。当这些变体实现为一个算法的类层次时,可以使用策略模式。
算法使用客户不应该知道的数据。可使用策略模式以避免暴露复杂的、与算法相关的数据结构。
一个类定义了多种行为,并且这些行为在这个类的操作中以多个条件语句的形式出现。将相关的条件分支移入它们各自的Strategy类中以代替这些条件语句。
总结简单工厂模式和策略模式
1.从类型上说:简单工厂模式属于创建型模式,而策略模式属于行为型模式。
2.接下来,看一个小例子:
斧子有很多种,有一个工厂专门负责生产各种需求的斧子。
工厂模式:
1)根据你给出的目的来生产不同用途的斧子,例如要砍人,那么工厂生产砍人斧子,要伐木就生产伐木斧子。
2)即根据你给出一些属性来生产不同行为的一类对象返回给你。
3)关注对象创建
策略模式:
1)用工厂生产的斧子来做对应的事情,例如用砍人的斧子来砍人,用伐木的斧子来伐木。
2)即根据你给出对应的对象来执行对应的方法。
3)关注行为的选择
3.简单工厂模式:根据客户选择的条件,来帮客户创建一个对象。
策略模式:客户给它一个创建好的对象,它来帮客户做相应的事
通过比较客户端的代码发现:
简单工厂模式:将对象的选择创建交给了简单工厂类,客户端只需要输入相应的条件就可以,不用负责对象的创建,但是需要客户端自己调用算法类的方法。但是一旦需要增加新的运算类,比如开根运算,就要去修改简单工厂类。
策略模式:对象的选择创建仍需要自己来做,但是将调用方法的职责交给了Context类。一旦需要增加新的策略需要修改客户端。
因此,简单工厂模式的缺点就是当有新的需求增加时,需要频繁的修改工厂类。只用策略模式,当有新的需求增加时需要修改的是客户端,客户端仍然承担着创建对象的职责,并没有减轻客户端的压力。而将这两种模式结合起来使用,则需要修改 Context 类,总之不是完美的。
Copyright © 2003-2013 www.wpsshop.cn 版权所有,并保留所有权利。