再回首,策略、简单工厂是否依然?

?这篇博客是好久之前就打好的草稿,可是一直就拖到了现在,刚好在保定上课,笔记本也排不上大用场,翻看手机,终于捡起了这些草稿,决定写完。

再说设计模式之前,我们先说说开闭原则。

一、开闭原则(ocp)

?以前读这些官方解释,总是觉得很官方,现在在读,觉得句句经典。和大家共享

?遵循开闭原则设计出的模块具有两个主要特点:

?(1)对于扩展是开放的(Open for extension)。这意味着模块的行为是可以扩展的。当应用的需求改变时,我们可以对模块进行扩展,使其具有满足那些改变的新行为。也就是说,我们可以增加模块的功能。

?(2)对于修改是关闭的(Closed for modification)。对模块行为进行扩展时,不必改动模块的源代码或者二进制代码。模块的二进制可执行版本,无论是可链接的库、DLL或者.EXE文件,都无需改动。

?注意:开闭原则是针对一个模块来说的,不然,开闭毫无意义。

?这两个模式是我们容易混淆的,因为从类图是看,基本是一样的。以前博客中都已经介绍过这几个设计模式,这里不做详细介绍,这篇博客是最近翻看笔记时的一点感触,来说说这两个设计模式的不同。

二、你还是你,我还是我——策略VS简单工厂

1、问题域不同

?首先看一下两个模式的定义:

    ?

?策略模式

?策略模式(Strategy):它定义了一系列的算法,并将每一个算法封装起来,而且使它们还可以相互替换。策略模式让算法的变化不会影响到使用算法的客户。

?简单工厂

简单工厂模式(Simple Factory Pattern)属于类的创新型模式,又叫静态工厂方法模式(Static FactoryMethod Pattern),是通过专门定义一个类来负责创建其他类的实例,被创建的实例通常都具有共同的父类。

?

最主要区别是就是:策略模式为行为型设计模式,而简单工厂为创建型模式。两个设计模式解决的问题域本就不同,侧重点不一样,放开眼界,学习这两个模式,不可一起咬住不放。

?

?2、开闭原则?

策略模式的?特点:创建,选择不同策略的责任在客户端。

?如果有扩展着怎么办呢?需要如下变动:

?    ?1:策略端增加新的策略类,无需改动已有的策略端代码————开闭原则

?    ?2:界面增加新策略字符串,客户端进行调用修改————客户端是无论如何都是要进行修改的。

那么我看简单工厂的特点:选择,创建的责任在算法端

?所以如有扩展,需要如下变动:

?    ?1:算法端增加新的算法类,调用算法的修改 还在 算法端,需要改动两处————违反开闭原则

?    ?2:客户界面增加选择新的算法的字符串————客户端是必定要修改的

这就是区别二,一个遵循了开闭原则,一个没有。还有一点就是,并不是不遵循开闭原则就一定不好,具体还是要看需求,具体对待。

宏观上问题域不同,细节上,是否需要遵循开闭原则,?这两点足以让我们可以适时的选择清楚简单工厂和策略模式了。?

三、策略 同 简单工厂

两个模式不考虑问题域的话,只看类图,都是通过继承来实现子类的扩张,都能解决动态变化的功能。因此都有一些共性:

   ?优点:

      ?1、 简化了单元测试,因为每个算法都有自己的类,可以通过自己的接口单独测试。

      2、 避免程序中使用多重条件转移语句,使系统更灵活,并易于扩展。

 缺点:

     1、 因为每个具体策略类都会产生一个新类,所以会增加系统需要维护的类的数量。

总结:其实23个设计模式,非要交合在一块说,那么我想说:都是相近的,因为他们统一的宗旨是:抽象,继承,多态,封装?,所以,设计模式每个和每个都有想象的地方,或许正因为是这样,才有的设模式的三大类:创建型,结构性,行为型之分,然后,每个小的区域内,又有各个不同的侧重点。

??这是我学习设计模式的一点小感悟:

?学习设计模式:不谋全局者,不足以某一域。

???使用设计模式:知其然,知其所以然。?

时间: 2024-10-13 17:01:14

再回首,策略、简单工厂是否依然?的相关文章

对设计模式的总结之简单工厂与策略模式

前言 面向对象编程追求的本质-提高扩展性.可维护性.灵活性和复用性.合理利用面向对象6个原则,能够很好的达到要求.如何利用好就是至关重要的了,前人总结了23+个设计模式能够让初学者更容易学到其中的精髓,本文就说说我对本人对简单工厂模式.策略模式的见解. 简单工厂模式与策略模式 简单工厂模式 工作中,常常遇到需要做一个功能(鸭子),这个功能中含有可控个数的子操作功能(鸭子叫,鸭子跑,鸭子飞),而且子功能在不同的情况下处理方式又不相同(成年鸭子/小鸭子叫,成年鸭子/小鸭子跑,成年鸭子/小鸭子飞).我

简单工厂、工厂方法、抽象工厂、策略模式、策略与工厂的区别

结合简单示例和UML图,讲解工厂模式简单原理. 一.引子 话说十年前,有一个爆发户,他家有三辆汽车(Benz(奔驰).Bmw(宝马).Audi(奥迪)),还雇了司机为他开车.不过,爆发户坐车时总是这样:上Benz车后跟司机说"开奔驰车!",坐上Bmw后他说"开宝马车!",坐上 Audi后他说"开奥迪车!".你一定说:这人有病!直接说开车不就行了?!而当把这个爆发户的行为放到我们程序语言中来,我们发现C语言一直是通过这种方式来坐车的!幸运的是这种有

设计模式笔记——策略模式VS简单工厂模式

策略模式VS简单工厂模式   策略模式(Strategy)它定义了算法家族,分别封装起来,让他们之间可以相互替换,此模式让算法的变化,不会影响到使用算法的客户. 1.组成 -抽象策略角色: 策略类,通常由一个接口或者抽象类实现. -具体策略角色:包装了相关的算法和行为. -环境角色:持有一个策略类的引用,最终给客户端调用. 2.应用场景 - 多个类只区别在表现行为不同,可以使用Strategy模式,在运行时动态选择具体要执行的行为. -需要在不同情况下使用不同的策略(算法),或者策略还可能在未来

简单工厂模式与策略模式的优缺点以及它们的区别

一.简单工厂模式 优点: 实现了对象创建和使用的分离; 客户端无须知道所创建的具体产品类的类名,只需要知道具体产品类所对应的参数即可; 通过引入配置文件,可以在不修改任何客户端代码的情况下更换和增加新的具体产品类,在一定程度上提高了系统的灵活性.  缺点: 工厂类集中了所有产品的创建逻辑,职责过重,一旦不能正常工作,整个系统都要受到影响; 增加系统中类的个数(引入了新的工厂类),增加了系统的复杂度和理解难度; 系统扩展困难,一旦添加新产品不得不修改工厂逻辑;   由于使用了静态工厂方法,造成工厂

设计模式之_简单工厂模式、工厂方法模式、抽象工厂模式 、策略模式、策略与工厂的区别(转)

一.前言 话说十年前,有一个爆发户,他家有三辆汽车(Benz(奔驰).Bmw(宝马).Audi(奥迪)),还雇了司机为他开车.不过,爆发户坐车时总是这样:上Benz车后跟司机说“开奔驰车!”,坐上Bmw后他说“开宝马车!”,坐上 Audi后他说“开奥迪车!”.你一定说:这人有病!直接说开车不就行了?!而当把这个爆发户的行为放到我们程序语言中来,我们发现C语言一直是通过这种方式来坐车的 幸运的是这种有病的现象在OO语言中可以避免了.下面以Java语言为基础来引入我们本文的主题:工厂模式! 二.简介

设计模式之策略模式&简单工厂模式

学习设计模式已经有非常长一段时间了,事实上先前已经敲过一遍了.可是老认为没有学到什么,认识也不够深刻.如今趁着重构机房,再又一次来过,也不晚. 事实上在敲了机房之后,看看模式,事实上,曾经非常难理解.非常难看懂的代码一眼就能够看懂了,趁着有点感觉了.早点收获吧. 简单工厂模式: 简单地说简单工厂模式:非常easy变化的地方,就能够用到简单工厂模式. 实例: 举个样例:我们在逛商场时.正好商场促销,各种优惠活动:有满300返100 ,有打8折的.抽奖等等吧. 促销来讲,各种优惠活动事实上就是变化.

简单工厂+策略模式-下

前言: 虽然做了个Demo但是实际应用的时候发现一开始对简单工厂与策略的理解有误差.开始想输入时间和基础数据就根据不同的算法算出来.后来发现不是.其实时间也是计算的数据.真正选择算法的是像固定用户和临时用户.或者说打折促销.根据这个. 深夜食堂 一个在深夜12点到凌晨7点开张的小食店.被大家称谓深夜食堂.菜单上只有一样菜.但是.无论你要点什么.只要老板会做.即使菜单上没有的菜也可以点.所以.客人还真不少呢. 日式滑动的木门被打开.进来的是一个浑身又绿色.有着硬壳的家伙.没错.他是富兰克林.老板,

设计模式(1)--简单工厂模式、策略模式

1. 简单工厂模式 在阎宏博士的<JAVA与模式>一书中开头是这样描述简单工厂模式的:简单工厂模式是类的创建模式,又叫做静态工厂方法(Static Factory Method)模式.简单工厂模式是由一个工厂对象决定创建出哪一种产品类的实例. 先放图再解释.下图一是从<大话设计模式>中摘出来的.问题是:用任意一种面向对象语言实现一个计算器控制台程序,要求输入两个数和运算符号,得到结果. 简单工厂模式实现的关键点有两个: 1. 继承:定义一个抽象父类“抽象产品”(Operation类

【设计模式】简单工厂模式与策略模式

[前言]今天再次把<大话设计模式>一书拿出来翻了一下,对于前面一节初探中讲诉的简单工厂模式和策略模式,有了更好的理解.按照习惯,还是继续梳理梳理. [简单工厂模式]:封装(数据+算法) 简单工厂模式的特点: 每一个子类最好能做到职责单一,将每一个需要涉及的数据和算法,封装成一个独立的类. 工厂模式中的工厂类其实起到了一个调度者的角色: 2.1 工厂类可以达到将实现具体逻辑的子类隐藏的效果,只需要将自己暴露调用实例化的接口,根据工厂类提供的对外方法,在内部实现逻辑判断,并最后实例化具体的子类对象