摘要：Command模式只是封装了一个没有任何变量的函数.interface Command{ void Excute();}具有强烈的分解功能的味道.把函数层面的任务提升到了类的层面(一个类仅仅是为了完成一个函数,而且没有该函数外的任何成员).简单的Command事件驱动的系统.Sensor(传感器)....
阅读全文
posted @ 2014-05-15 09:47
随笔分类 - 设计模式
摘要：继承program by difference.通过继承,可以建立完整的软件结构分层.其中每一层都可以重用该层次以上的Code.过度使用继承的代价是巨大的.应使用组合或者委托来替代继承.Template Method(使用继承)和Strategy(使用委托)模式解决了相同的问题:分离通用的算法和具体...
阅读全文
posted @ 2014-05-15 09:46
摘要：类和实例对于大多数的类,都可以创建多个实例.在需要和不需要时,创建和删除这些实例.该过程会伴随着内存的分配和归还.同时,有一些类,应该仅有一个实例.该实例在程序启动/结束时被创建和删除.root对象.通过该对象可以得到系统中的其他对象.factory对象.用来创建系统中的其他对象.manager对象...
阅读全文
posted @ 2014-05-15 09:45
摘要：去除代码中的if(obj==null),或者try/catch语句.维持Code的一致性.Null对象,代表"什么也不做"的一个对象.使Null对象称为一个匿名内部类确保了该类只有单一实例.并且客户无法创建Null对象的其他实例.可以使用if(obj== Employee.Null)表达.[Agil...
阅读全文
posted @ 2014-05-15 09:44
摘要：使用new的Code都违反了DIP.但是,依赖于稳定的具体类,是无害的.例如string.另一方面,对于正在开发中的APP,很多具体类是易变的.此时应该依赖于抽象接口.Factory模式:只依赖于抽象接口就能创建出具体对象的实例.对Test Fixture使用工厂编写UT时,希望把一个模块和它使用的...
阅读全文
posted @ 2014-05-15 09:42
摘要：[Agile Software Development(Principles,Patterns,and Pracitices)]
阅读全文
posted @ 2014-05-15 09:41
摘要：拉模式.Observer实现了一种间接关系.可以向各种对象注册观察者.可以有效地管理依赖关系.拉模式实现简单,且Subject和Observer可以成为类库中的可重用元素.当被观察对象比较复杂,并且Observer需要一个提示,那么使用推模式.该模式的目的:增加新的Observer对象时,无需更改被...
阅读全文
posted @ 2014-05-15 09:40
摘要：简易的台灯Abstract Server模式谁拥有接口.接口属于它的客户,而不是它的派生类.接口和客户之间的逻辑关系,强于接口和其派生类的逻辑关系.逻辑关系和实体关系的强度是不一致的.在实体关系上,继承比依赖更强.最好将接口和它的客户打包,而不是和它的派生类在一起.Adapter模式当Light不能...
阅读全文
posted @ 2014-05-15 09:39
摘要：软件中的Barrier.数据从程序移到DB中时,要跨越数据库的Barrier.消息从一个PC到另一个PC时,要跨越网络Barrier.跨越可能是复杂的,很可能处理Barrier的Code会多于处理本来要解决的问题的Code.Proxy模式.DB和ProductIMP这两个协作对象互相不可见.Prox...
阅读全文
posted @ 2014-05-15 09:38
摘要：Modem结构Visitor模式对于被访问(Modem)层次结构中的每一个派生类,访问者(Visitor)层次中都有一个对应的方法.从派生类到方法的90度旋转.新增类似的Windows配置函数时,Visitor模式使用Visitor派生类来代替了被访问者结构中的方法.双重分发:accept()+vi...
阅读全文
posted @ 2014-05-15 09:37
摘要：地铁十字转门状态迁移表格.起始状态 触发迁移的事件 终止状态 要执行的动作.Locked Coin UnLocked UnLockUnLocked Pass LockedLock最直接的方式:switch(state) case Locked : switch(event) case Pass:St...
阅读全文
posted @ 2014-05-15 09:36
摘要：Agility,指以微小增量的方式构建软件.全局视图和软件一起演化.每次迭代中,都使设计尽可能适合于当前系统,而不会花时间去预测未来的需求,更不会试图构建一些基础结构去支撑未来才需要的特性.更关注的是当前的系统.不进行预先设计,不需要成熟的初始设计.而保持设计尽可能的干净,简单.并使用单元测试和验收...
阅读全文
posted @ 2014-05-15 09:12
摘要：一个类应仅有一个引起它变化的原因.内聚性.每个Responsibility都是变化的一个轴线.当需求变化时,该变化会反映为类的职责的变化当一个类耦合了多个职责时,一个职责的变化会消弱或抑制其他职责的能力.这种耦合导致了fragile的设计.职责.A reson for change.一个类负担的N个...
阅读全文
posted @ 2014-05-15 09:10
摘要：对于僵化性的臭味,应用OCP原则之后,再进行同样的改动时,只需添加新代码,而不必改动已正常运行的代码.扩展模块行为的方式通常是修改模块的Code,不允许修改的模块常常被认为是具有固定的行为.Open:模块的行为是可以扩展的,即可以改变模块的功能.Close:对模块进行扩展时,不必改动DLL,Code...
阅读全文
posted @ 2014-05-15 09:09
摘要：OCP中,继承支持了抽象和多态特性.LSP:子类必须能够替换掉其基类.反例:使用if/else判断类型,以便选择针对特定类型的正确行为.有效性并非本质属性模型的有效性,只能通过它的客户程序来表现.在考虑一个特定设计是否合理时,必须要根据该设计的使用者所作出的合理假设来审视它.这些合理的假设常常就是单...
阅读全文
posted @ 2014-05-15 09:08
摘要：高层模块不应该依赖于底层模块，二者都应该依赖于抽象;细节应依赖于抽象.传统习惯中,高层模块依赖于底层模块,策略依赖于细节的结构.这是要定义子程序层次结构,该层次结构描述了高层模块如何调用底层模块.但是,这也就意味着,底层模块的更改会直接影响到高层模块.而APP的区别就是体现在这些高层模块中的.包含高...
阅读全文
posted @ 2014-05-15 09:07
摘要：ISP用来处理fat接口的缺点.如果类的接口不是内聚的,那么该类就具有fat接口.fat接口可以分解为多个组.每个组服务于不同的客户.ISP承认不需要内聚接口的对象.但是建议客户不应该看到它作为单一的类而存在.客户程序看到的应该是多个具有内聚接口的抽象基类.接口污染.分离客户就是分离接口.客户对接口...
阅读全文
posted @ 2014-05-15 09:06
摘要：包的设计.通过把类组织成package,可以在更高层次的抽象上理解设计.通过包来管理软件的开发和发布.由于类之间的相互依赖关系,包之间会产生依赖关系.包的依赖关系展示了APP的高层组织结构.粒度:内聚性."自顶向上"的将类划分到包中Reuse-Release Equivalence Priciple...
阅读全文
posted @ 2014-05-15 09:04
浙公网安备 33010602011771号