Luke笔记——设计模式

某天面试有一道题目,请描述Struts、Spring、Hibernate之间的关系....

我的回答是:
Struts = 公关部
Spring = 人事部(应该还加上行政部)
Hibernate = 后勤部

 

在那天也发觉到自己的设计模式了解得还不太够,特别是没例子能立刻说出对模式的理解,干脆用一个公司为对象,一边查资料一边用自己的理解写些故事。

 

 


故事——
BOSS:我昨天要的设计资料呢?
经理:开发部正在写....
BOSS:那研究资料呢??
经理:技术部正在写....
BOSS:@#¥@¥@.....要写到哪年哪月啊???

分析——
这里有几个工厂?两个?.....开发部和技术部???
错了!!!!!
这里有三个工厂,开发部和技术部是两个实例工厂,经理是抽象工厂!
老板不管资料怎么写出来,他只要问经理要就行了,很典型的客户需求。
经理也不是写资料的人,他安排部门人员去写就行了,有点门面模式的味道吧?但是在老板来说,经理就是产出报告的工厂。
开发部和技术部是不同的部门,能产出也就能当它是工厂了,但是他们所能够产出的产品是不一样的。

 

简单的理解——
工厂模式最常用于完成批量任务,当任务内容有不同但类型一致的时候,可建立抽象工厂(也就是负责人)统一对外衔接。

 

Simple Factory  (简单工厂) —对象创建型模式
最常用的工厂模式,就是将大量的重复性创建工作提取出来,由一个专门的创建类代为实现。

Abstract Factory (抽象工厂) —对象创建型模式
概念性比较多的东西,可以看作工厂模式的拓展或者细化。
建立一个空的工厂面向使用者,针对使用者的不同需要引入不同的施工队伍做实际的事情,而使用者的操作不需要改变。
更形象点就是皮包公司。

 

 


故事——
BOSS:我昨天要的设计资料和研究资料呢?
经理:已经写完了。
BOSS:那营运资料呢??
经理:开发部和技术部都不会写这个资料,但是文档目录已经添加了,配套的资料也完成了,就等市场部那边来填了。
BOSS:@#¥@¥@.....要写到哪年哪月啊???

分析——
营运资料不是当前能够满足实现的,但已经确定是必须要写的,不填写完,整份文档就不能算完工。
工厂方法也一样,它是一个已实现的方法,但是对暂时无法实现的问题进行提取,先处理除问题外的其它条件。让整个实现流程在问题解决前就已经准备好,不用等问题解决才能进行下一步工作。

 

Factory Method  (工厂方法) —对象创建型模式

 

 


故事——
BOSS:好,今天公司分出各部门,进行分工合作!
George:怎么个分工合作法?
BOSS:项目开发任务就由开发部完成,技术研究任务就由技术.....就像这样。
George:啊?那我去哪个部门?
BOSS:你当大内总管.....我就问你进展就好了(嘿嘿嘿嘿....)
George:!@¥#¥%¥@#×&#%......

分析——
老板继续当典型的客户,经理在这里成了‘建筑师’或者说控制人,按照规划好的资料,看情况安排不同的部门进行工作,搭建出整个项目来。
这里不是‘经理’是建筑模式,而是经理与下属部门的指挥、合作的这个“谁的活谁干”的模式叫建筑模式。
前提是指挥者必须有规划好的资料或者说项目蓝图,因为‘建筑师’在建筑过程中必须调用不同的‘施工队伍’,得有足够的根据和规划。

Builder   (建筑) —对象创建型模式

 

 

 

故事——
小甲:经理,这些资料不用写那么详细了吧,还留着干嘛?
经理:存档啊!
老板:存着干嘛,浪费空间.....
经理:把这份文档当模板,以后对着照抄就行了。
小甲:对哦!好事情....
老板:嗯,不错,那要写好一点!
经理:好的老板.....小甲写得不错,就交给小甲吧!
小甲:!@#%#!#¥!......

分析——
模板这个词本身就很好地代表了原型这种模式,抽象出来的Base类也是原型模式的一种实现例子。

Prototype  (原型) —对象创建型模式

 

 

 

故事——
George:今天安排一下这个项目的任务安排。
Ailice:不用说,又是我全程文档记录的了?!
George:聪明!乖,做完给糖吃,呵呵.....
Andy:经理,我不要再做测试了,上个项目我做过了。
George:你不做还有谁做啊?
Andy:阿甲做测试也不错啊,他行的!
George:哦,对!正好!就那么定了,Andy负责全局测试计划,阿甲交给你负责局部测试吧。
Andy:@¥@&@¥#……@&……

分析——
这里有几个Singleton?
3个?开玩笑,当然是4个.....
爱丽丝一个人负责全程文档记录,那就是“文档处理类”的单例(全局单例)
安迪也是独自负责全局测试兼主测试,相当于“测试总计划”,也是单例。(全局单例)
阿甲呢?并没有贯穿全项目的任务,但是在测试计划的各阶段里面都被安迪所调用,独立完成阶段性测试,相当于各阶段来说,也是单例。(局部单例)
还有谁呢?当然是经理乔治。
乔治一个人负责全项目的任务安排、进度掌控,他当然也是一个单例。(全局单例)
同时,他也是一个Builder,安排各人完成工作。

Singleton  (单例) —对象创建型模式

 

 

 

 

 

 

 




发觉写故事很是浪费时间,而且在学习过程中发现这些模式已经在现实生活中相当普遍地使用了。
设计模式不是死的,是日常经常使用到的,明白了解决方案并在实际中用到就是最好的例子。
所以,还是用最简单的话描述吧。

 

 

 

Adapter   (适配器) —类对象结构型模式
转接口,最典型就是SOA模型中各个不同组件之间的交流,都是通过一个Adapter将交流的语言、标准统一起来。

 

Bridge   (桥接) —对象结构型模式
跳线,将固定结构改为可跳转结构,使得组件之间的关系更为灵活和多变,以适应不同的需求。

 

Composite  (组成) —对象结构型模式
组装,将零散组件组装起来构成一个整体,电脑城的组装电脑店天天在做这个事情。传说中的积木型软件就是最好的示例。

 

Decorator  (装饰) —对象结构型模式
插件,插件不是装饰模式的全部,它可以看成是装饰模式的样例。重点在于主程序,插件只是拓展了主程序。

 

Facade   (门面/外观) —对象结构型模式
前台,来什么人做什么事都由前台应对,然后再转交相关的人去处理。

 

Flyweight  (享元) —对象结构型模式
连接池就是很典型的享元模式,另外游戏也是最常用享元的例子,游戏里面的怪物原型就是共享的“元”。

 

Proxy   (代理) —对象结构型模式
考试的时候请个人帮你去考试,那就叫作弊,同时也叫代考,那个帮你作弊的人就是你的代理,换成90后说法叫假面。

 

Interpreter  (解释器) —类行为型模式
在公司发展了一个地下mm,并且约定好,她站窗边看风景的时候端的是咖啡就看电影,端牛奶就逛街,白开水就.....
解释器模式就是这约定的‘密码’(文本)、‘加密方法’(语法)、‘解密工具’(解析器)等整套的组合。

 

Template Method  (模板方法) —类行为型模式
模板模式和策略模式的组合模式(拗口吧?),哈哈....
将策略以模板的方式定制出大致流程,但是预留细节,并强迫子类实现流程内容。

 

Chain of Responsibility (职责链) —对象行为型模式
多个桥接模式模式的组合,一层层的将处理职责转交下一处理对象,形成处理链,客户用不管到底谁处理
以Struts2为例,请求递交到应用服务器,应用服务器转交过滤器,过滤器根据配置转交相应的Action,Action转Service....
像Exception的thrown处理,捉住了只管往外抛,不管到底谁处理。

 

Command   (命令) —对象行为型模式
讲指令进行包装,然后发送通知,讲指挥者和执行者进行解耦。有点像线程Sleep之后等通知。

 

Iterator  (迭代器) —对象行为型模式
Collection就最明显的例子,继承Collection的List、Set都提供了方法让使用者可以访问内部元素而又不用透露内部细节。

 

Mediator  (调停者) —对象行为型模式
解决纷争手段,淘宝的支付宝就是很好的例子,预支的都先给我,付款也由我来付,我做裁判。

 

Memento   (备忘录) —对象行为型模式
QQ的消息记录,Google的网页快照都是很好的例子,把对象按照当时状态保存一份,在需要时候可以还原出来。

 

Observer  (观察者) —对象行为型模式
网页流量统计、监听、数据库的触发器都是很好的例子,当状态产生变化,观察者进行记录并通知关注该信息的相关对象。

 

State   (状态) —对象行为型模式
最常用和适合解决的就是开关类型的问题,相当于一个大型的switch...case...判断,只不过这个判断太重要或者太常用了,所以把这个判断独立抽取出来,专门用一个控制类进行管理。

 

Strategy  (策略) —对象行为型模式
就是计划好了,什么样的问题用什么样的解决方法去应对,设计模式本身就是策略的一种

 

Visitor   (访问者) —对象行为型模式
访问者模式是针对未知或未定数据结构的处理问题解决方案,将数据结构与数据处理进行解耦。
就像客户回访一样,客户是不同的,客户问题也可能不同,无法用固定模式去进行处理。那么只需要一个访问者去应对不同的客户的不同需求,就可以不改变公司和客户两者的同时将两者沟通起来。
也可以看作是一对多的桥接模式。

 

 

惯例PS:

发现文章有错的请通知我,非常感谢!

来过的朋友请顺便踩一脚......^_^

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值