随笔分类 -  设计模式

23种设计模式.
依赖注入与Service Locator
摘要：为什么需要依赖注入?ServiceUser是组件,在编写者之外的环境内被使用,且使用者不能改变其源代码.ServiceProvider是服务,其类似于ServiceUser,都要被其他应用使用,不同是ServiceProvider会被用于非本地环境,需要对应不同环境.普通的ServiceUser来负... 阅读全文
posted @ 2014-06-24 14:02 robynhan 阅读(2040) 评论(0) 推荐(0)
MVP演化论
摘要：本文是翻译MVP: Model-View-Presenter The Taligent Programming Model for C++ and Java(Mike Potel)文章的摘要.该文介绍了从MVC到MVP的思想演化过程.SmallTalk编程模型在该项目中,使用了MVC来实现GUI(... 阅读全文
posted @ 2014-06-23 18:11 robynhan 阅读(358) 评论(1) 推荐(0)
应用MVP模式对遗留代码进行重构
摘要：AV(Autonomous View)自治视图在面向终端用户的应用中,都需要一个可视化的UI来与用户交互.这个UI称为View视图.在早期,我们习惯将所有前台的逻辑,与视图揉在一起,称为AV自治视图.这些逻辑包括:数据呈现(Display),用户动作的扑捉与响应,数据存储等.在.Net的Winfor... 阅读全文
posted @ 2014-06-20 12:15 robynhan 阅读(833) 评论(4) 推荐(1)
State模式
摘要：地铁十字转门状态迁移表格.起始状态 触发迁移的事件 终止状态 要执行的动作.Locked Coin UnLocked UnLockUnLocked Pass LockedLock最直接的方式:switch(state) case Locked : switch(event) case Pass:State模式State/Strategy模式都有一个Context,其委托给一个具有几个派生类的多态基类.不同:State模式中的派生类持有回指向Context的引用.派生类的主要功能时使用这个引用来调用Context中的方法.所有State模式实例都是Strategy模式实例.反之不成立.State 阅读全文
posted @ 2013-12-14 15:49 robynhan 阅读(271) 评论(0) 推荐(0)
Visitor模式,Decorator模式,Extension Object模式
摘要：Modem结构Visitor模式对于被访问(Modem)层次结构中的每一个派生类,访问者(Visitor)层次中都有一个对应的方法.从派生类到方法的90度旋转.新增类似的Windows配置函数时,Visitor模式使用Visitor派生类来代替了被访问者结构中的方法.双重分发:accept()+visit()两个动态分发.形成了一个功能矩阵:不同类型的Modem的轴线+不同OS的轴线.每一个单一都被一个功能(描绘了特定的Modem在特定的OS中使用的)填充.Acyclic Visitor模式Visitor模式的问题Modem依赖于ModemVisitor.依赖环:Modem中每一个派生类在Vi 阅读全文
posted @ 2013-12-14 14:38 robynhan 阅读(494) 评论(0) 推荐(0)
Proxy模式:管理第三方API
摘要：软件中的Barrier.数据从程序移到DB中时,要跨越数据库的Barrier.消息从一个PC到另一个PC时,要跨越网络Barrier.跨越可能是复杂的,很可能处理Barrier的Code会多于处理本来要解决的问题的Code.Proxy模式.DB和ProductIMP这两个协作对象互相不可见.Proxy负责连接两者.这样,Proxy模式跨越了Barrier,而且不会影响到任何一个参与者.关注点分离:业务逻辑和数据库.Proxy变成了一个很重的点,Application和API的映射集中在Proxy上,两者的改变都会导致Proxy更改.[Agile Software Development(Pri 阅读全文
posted @ 2013-12-13 16:03 robynhan 阅读(314) 评论(0) 推荐(0)
Abstract Server模式,Adapter模式和Bridge模式
摘要：简易的台灯Abstract Server模式谁拥有接口.接口属于它的客户,而不是它的派生类.接口和客户之间的逻辑关系,强于接口和其派生类的逻辑关系.逻辑关系和实体关系的强度是不一致的.在实体关系上,继承比依赖更强.最好将接口和它的客户打包,而不是和它的派生类在一起.Adapter模式当Light不能继承Switchable接口时(第三方代码).Modem Client仍然看到的是期望的连接行为,而Ded User不必去调用根本无用的Dial/Hangup().仍然存在杂凑体.Adapter仍然要模拟连接动作.但是依赖关系都存在于Adapter上,其对User是隐藏的.只有factory才会依赖 阅读全文
posted @ 2013-12-13 10:12 robynhan 阅读(462) 评论(0) 推荐(0)
Observer模式
摘要：拉模式.Observer实现了一种间接关系.可以向各种对象注册观察者.可以有效地管理依赖关系.拉模式实现简单,且Subject和Observer可以成为类库中的可重用元素.当被观察对象比较复杂,并且Observer需要一个提示,那么使用推模式.该模式的目的:增加新的Observer对象时,无需更改被观察的对象.被观察对象保持了封闭.OCP.模式的形成.朝着正在编写的代码的需要方向去演化代码.在重构代码以解决耦合性,简单性,以及表达性的问题时.代码可能已经接近于一个特定的模式了.重命名类和变量的名称,并修改结构以符合更正规的模式形式,这样,代码回归为模式.优先考虑测试,有助于将设计中的耦合减至最 阅读全文
posted @ 2013-12-12 19:23 robynhan 阅读(226) 评论(0) 推荐(0)
Composite模式
摘要：[Agile Software Development(Principles,Patterns,and Pracitices)] 阅读全文
posted @ 2013-12-12 17:13 robynhan 阅读(109) 评论(0) 推荐(0)
Factory模式
摘要：使用new的Code都违反了DIP.但是,依赖于稳定的具体类,是无害的.例如string.另一方面,对于正在开发中的APP,很多具体类是易变的.此时应该依赖于抽象接口.Factory模式:只依赖于抽象接口就能创建出具体对象的实例.对Test Fixture使用工厂编写UT时,希望把一个模块和它使用的模块隔离起来,从而单独测试该模块的行为.工厂的使用遵循DIP,对于系统中所有的易变类都要使用工厂.但是,工厂是复杂的,为了创建一个新类,需要1个表示该类的接口和1个其工厂的接口.实现这两个接口的具体类.使得高层决策模块在创建类的实例时无需依赖这些类的具体实现.使得一组类的完全不同系列的实现间进行切换 阅读全文
posted @ 2013-12-12 16:40 robynhan 阅读(201) 评论(0) 推荐(0)
包的设计原则
摘要：包的设计.通过把类组织成package,可以在更高层次的抽象上理解设计.通过包来管理软件的开发和发布.由于类之间的相互依赖关系,包之间会产生依赖关系.包的依赖关系展示了APP的高层组织结构.粒度:内聚性."自顶向上"的将类划分到包中Reuse-Release Equivalence Priciple(REP).重用的粒度就是发布的粒度.重用类库时,我们要求author维护Code,同时在接口和功能改变时通知我们(同时我们有拒绝改变的权利).重用性必须基于包,可重用的包必须包含可重用的类.包中的所有类应该对于同一类用户来说都是可重用的.Common-Reuse Princip 阅读全文
posted @ 2013-12-12 15:10 robynhan 阅读(824) 评论(0) 推荐(0)
Null Object模式
摘要：去除代码中的if(obj==null),或者try/catch语句.维持Code的一致性.Null对象,代表"什么也不做"的一个对象.使Null对象称为一个匿名内部类确保了该类只有单一实例.并且客户无法创建Null对象的其他实例.可以使用if(obj== Employee.Null)表达.[Agile Software Development(Principles,Patterns,and Pracitices)] 阅读全文
posted @ 2013-12-10 17:32 robynhan 阅读(174) 评论(0) 推荐(0)
Singleton模式和Mono-State模式
摘要：类和实例对于大多数的类,都可以创建多个实例.在需要和不需要时,创建和删除这些实例.该过程会伴随着内存的分配和归还.同时,有一些类,应该仅有一个实例.该实例在程序启动/结束时被创建和删除.root对象.通过该对象可以得到系统中的其他对象.factory对象.用来创建系统中的其他对象.manager对象.负责管理和控制其他对象.对于这些对象,如果创建了多份,那么就会发生逻辑错误.通常情况下,强制对象单一性的机制有些多余.完全可以在程序启动时只创建该对象的一个实例.不过,使用模式能够传达我们的意图(该类仅能有一个实例).代价/收益:如果强制对象单一性的机制是轻量级的.那么传达意图的收益会胜过实施这些 阅读全文
posted @ 2013-12-10 17:07 robynhan 阅读(433) 评论(0) 推荐(0)
Template Method模式和Strategy模式[继承与委托]
摘要：继承program by difference.通过继承,可以建立完整的软件结构分层.其中每一层都可以重用该层次以上的Code.过度使用继承的代价是巨大的.应使用组合或者委托来替代继承.Template Method(使用继承)和Strategy(使用委托)模式解决了相同的问题:分离通用的算法和具体的上下文(DIP).Template Method模式.Strategy模式Template Method模式允许一个通用算法操纵多个可能的具体实现.而完全遵循DIP的Strategy模式,允许每一个具体实现都可以被多个不同的通用算法操纵.总结.两者都用来分离高层算法和底层的具体实现.都允许高层算法 阅读全文
posted @ 2013-12-10 10:14 robynhan 阅读(196) 评论(0) 推荐(0)
Command模式
摘要：Command模式只是封装了一个没有任何变量的函数.interface Command{ void Excute();}具有强烈的分解功能的味道.把函数层面的任务提升到了类的层面(一个类仅仅是为了完成一个函数,而且没有该函数外的任何成员).简单的Command事件驱动的系统.Sensor(传感器).驱动者.只负责监听事件,并在事件发生后,调用绑定的Command的Excute方法.而不知道具体绑定的是什么样的Command.Command只负责执行具体的命令逻辑.两者的绑定关系可以定义于系统主体之外(xml文件etc.)事务操作.解除了 从用户获取数据,验证并操作数据,业务对象本身的耦合关系. 阅读全文
posted @ 2013-12-09 15:21 robynhan 阅读(455) 评论(0) 推荐(0)