saville

博客园 首页 新随笔 联系 订阅 管理

随笔分类 -  设计模式

上一页 1 2

摘要:一、概述在软件开发中,对某一项操作往往有固定的算法结构,而具体的子步骤会因为不同的需要而有所不同。如何可以在稳定算法结构的同时来灵活应对子步骤变化的需求呢?二、模板方法模板方法是一种常见的设计模式,它定义一个操作中的算法的骨架,而将一些步骤延迟到子类中。模板使得子类可以不改变一个算法的结构即可重定义该算法的某些特定步骤。模板方法的结构图如下AbstractClass是抽象类,定义了抽象的操作ConcreteClass实现了抽象操作中与子类相关的特定步骤。三、示例在这里以实现一个公司的薪资系统为例介绍一下模板方法的应用。首先定义抽象类,一般建议将抽象的操作定义为非虚public方法,将子类需要定 阅读全文
posted @ 2011-09-14 14:34 saville 阅读(9920) 评论(2) 推荐(0) 编辑

摘要:一、概述通常来说,“行为请求者”与“行为实现者”是紧耦合的。但在某些场合,比如要对行为进行“记录、撤销/重做、事务”等处理,这种无法抵御变化的紧耦合是不合适的。在这些情况下,将“行为请求者”与“行为实现者”解耦,实现二者之间的松耦合就至关重要。命令模式是解决这类问题的一个比较好的方法。二、命令模式命令模式将一个请求封装为一个对象,从而使你可用不同的请求对客户进行参数化;对请求排队或记录请求日志,以及支持可撤销的操作。命令模式的结构图如下Command定义了命令的接口ConcreteCommand实现Command接口,定义了具体的命令Client用于创建具体的命令并设定接收者Invoker要求 阅读全文
posted @ 2011-08-17 10:20 saville 阅读(3820) 评论(1) 推荐(0) 编辑

摘要:一、例子在软件开发中,我们往往会想要给某一类对象增加不同的功能。比如要给汽车增加ESP、天窗或者定速巡航。如果利用继承来实现,就需要定义无数的类,Car,ESPCar,CCSCar,SunRoofCar,ESPCCSCar……很容易就导致“子类爆炸”问题。上述“子类爆炸”问题的根源在于该解决方案利用继承来扩展功能,缺乏灵活性。那么如何能在扩展功能的同时避免“子类爆炸”呢?二、装饰者模式装饰者模式装饰者模式可以动态地给一个对象增加一些额外的职责。就增加功能来说,装饰者模式相比生成子类更为灵活。装饰者模式的结构图如下Component定义了一个接口,可以利用Decorator为实现了这个接口的对象 阅读全文
posted @ 2011-07-19 17:17 saville 阅读(7823) 评论(9) 推荐(0) 编辑

上一页 1 2