04 2011 档案

摘要:概述 变化一直以来都是软件设计的永恒话题,在XP编程中提倡拥抱变化,积极应对。如何更好的去抓住变化点,应对变化?如何更好的提高代码复用?通过学习Template Method模式,您应该有一个新的认识。 意图 定义一个操作中的算法的骨架,而将一些步骤延迟到子类中。Template Method使得子类可以不改变一个算法的结构即可重定义该算法的某些特定步骤。[-GOF《设计模式》] 结构图 图1 T... 阅读全文
posted @ 2011-04-28 21:12 spring yang 阅读(1884) 评论(7) 推荐(4) 编辑
摘要:概述面向对象的思想很好地解决了抽象性的问题,一般也不会出现性能上的问题。但是在某些情况下,对象的数量可能会太多,从而导致了运行时的代价。那么我们如何去避免大量细粒度的对象,同时又不影响客户程序使用面向对象的方式进行操作?意图运用共享技术有效地支持大量细粒度的对象。[GOF 《设计模式》]结构图1.单纯享元模式的结构在单纯享元模式中,所有的享元对象都是可以共享的。单纯享元模式所涉及的角色如下:抽象享元(Flyweight)角色:此角色是所有的具体享元类的超类,为这些类规定出需要实现的公共接口。那些需要外蕴状态(External State)的操作可以通过调用商业方法以参数形式传入。具体享元(Co 阅读全文
posted @ 2011-04-27 21:53 spring yang 阅读(1594) 评论(2) 推荐(5) 编辑
摘要:概述 在软件开发系统中,客户程序经常会与复杂系统的内部子系统之间产生耦合,而导致客户程序随着子系统的变化而变化。那么如何简化客户程序与子系统之间的交互接口?如何将复杂系统的内部子系统与客户程序之间的依赖解耦?这就是要说的Façade 模式。重新进行类的设计,将原来分散在源码中的类/结构及方法重新组合,形成新的、统一的接口,供上层应用使用。 Facade所面对的往往是多个类或其它程序单元,通过重新组... 阅读全文
posted @ 2011-04-25 22:10 spring yang 阅读(2855) 评论(2) 推荐(2) 编辑
摘要:概述 组合模式有时候又叫做部分-整体模式,它使我们树型结构的问题中,模糊了简单元素和复杂元素的概念,客户程序可以向处理简单元素一样来处理复杂元素,从而使得客户程序与复杂元素的内部结构解耦。 描述Composite模式的最佳方式莫过于树形图。从抽象类或接口为根节点开始,然后生枝发芽,以形成树枝节点和叶结点。因此,Composite模式通常用来描述部分与整体之间的关系,而通过根节点对该结构的抽象,使得... 阅读全文
posted @ 2011-04-24 23:21 spring yang 阅读(1869) 评论(0) 推荐(4) 编辑
摘要:概述 在软件系统中,有时候我们会使用继承来扩展对象的功能,但是由于继承为类型引入的静态特质,使得这种扩展方式缺乏灵活性;并且随着子类的增多(扩展功能的增多),各种子类的组合(扩展功能的组合)会导致更多子类的膨胀。如何使“对象功能的扩展”能够根据需要来动态地实现?同时避免“扩展功能的增多”带来的子类膨胀问题?从而使得任何“功能扩展变化”所导致的影响将为最低?这就是本文要讲的Decorator模式。 ... 阅读全文
posted @ 2011-04-23 00:24 spring yang 阅读(2381) 评论(7) 推荐(4) 编辑
摘要:概述 在软件系统中,某些类型由于自身的逻辑,它具有两个或多个维度的变化,那么如何应对这种“多维度的变化”?如何利用面向对象的技术来使得该类型能够轻松的沿着多个方向进行变化,而又不引入额外的复杂度?这就要使用Bridge模式。 桥梁模式是一个非常有用的模式,也是比较复杂的一个模式。熟悉这个模式对于理解面向对象的设计原则,包括"开-闭"原则(OCP)以及组合/聚合复用原则(CARP)都很有帮助。理解好... 阅读全文
posted @ 2011-04-20 23:12 spring yang 阅读(2726) 评论(6) 推荐(3) 编辑
摘要:概述 在软件构建过程中,我们需要为某些对象建立一种“通知依赖关系” ——一个对象(目标对象)的状态发生改变,所有的依赖对象(观察者对象)都将得到通知。如果这样的依赖关系过于紧密,将使软件不能很好地抵御变化。使用面向对象技术,可以将这种依赖关系弱化,并形成一种稳定的依赖关系。从而实现软件体系结构的松耦合。 一个软件系统常常要求在某一个对象的状态发生变化的时候,某些其它的对象做出相应的改变。做到这一点... 阅读全文
posted @ 2011-04-19 23:37 spring yang 阅读(2818) 评论(4) 推荐(1) 编辑
摘要:概述 在面向对象的软件设计中,我们经常会遇到一类集合对象,这类集合对象的内部结构可能有着各种各样的实现,但是归结起来,无非有两点是需要我们去关心的:一是集合内部的数据存储结构,二是遍历集合内部的数据。面向对象设计原则中有一条是类的单一职责原则,所以我们要尽可能的去分解这些职责,用不同的类去承担不同的职责。Iterator模式就是分离了集合对象的遍历行为,抽象出一个迭代器类来负责,这样既可以做到不暴... 阅读全文
posted @ 2011-04-18 23:36 spring yang 阅读(2430) 评论(5) 推荐(1) 编辑
摘要:概述在软件系统中,有时候面临着“一个复杂对象”的创建工作,其通常由各个部分的子对象用一定的算法构成;由于需求的变化,这个复杂对象的各个部分经常面临着剧烈的变化,但是将它们组合在一起的算法确相对稳定。如何应对这种变化?如何提供一种“封装机制”来隔离出“复杂对象的各个部分”的变化,从而保持系统中的“稳定构建算法”不随着需求改变而改变?这就是要说的建造者模式。本文通过现实汽车生产中的例子,来诠释建造者模式。意图将一个复杂的构建与其表示相分离,使得同样的构建过程可以创建不同的表示。<Design Pattern>Builder模型图通俗讲解:Builder模式的理解 建造者(Builder 阅读全文
posted @ 2011-04-18 20:00 spring yang 阅读(2600) 评论(8) 推荐(1) 编辑
摘要:概述 在软件系统中,“行为请求者”与“行为实现者”通常呈现一种“紧耦合”。但在某些场合,比如要对行为进行“记录、撤销/重做、事务”等处理,这种无法抵御变化的紧耦合是不合适的。在这种情况下,如何将“行为请求者”与“行为实现者”解耦?将一组行为抽象为对象,可以实现二者之间的松耦合。这就是本文要说的Command模式。 意图 将一个请求封装为一个对象,从而使你可用不同的请求对客户进行参数化;对请求排队或... 阅读全文
posted @ 2011-04-13 22:57 spring yang 阅读(3583) 评论(9) 推荐(5) 编辑
摘要:概述允许一个对象在其内部状态改变时改变它的行为。对象看起来似乎修改了它所属的类。意图状态模式主要解决的是当控制一个对象状态装换的条件表达式过于复杂时的情况。把状态的判断逻辑转移到表示不同状态的一系列类中,可以把复杂的判断逻辑简单化。当一个对象行为取决于它的状态,并且它必须在运行时刻根据状态改变它的行为时,就可以考虑使用状态模式了。<Design Pattern>State模式结构图示例关系图描述: 一年有12个月,有四个季度,每个月都有一属于一个季度,根据月份得到这个季度的天气信息.可以用State模式来实现.关系图:代码设计:先创建接口IQuarter.cs: public in 阅读全文
posted @ 2011-04-11 23:13 spring yang 阅读(2523) 评论(8) 推荐(1) 编辑
摘要:概述 在软件系统中,有些对象有时候由于跨越网络或者其他的障碍,而不能够或者不想直接访问另一个对象,如果直接访问会给系统带来不必要的复杂性,这时候可以在客户程序和目标对象之间增加一层中间层,让代理对象来代替目标对象打点一切。这就是本文要说的Proxy模式。 意图 代理(Proxy)模式给某一个对象提供一个代理,并由代理对象控制对原对象的引用。 代理模式的英文叫做Proxy或Surrogate,中文... 阅读全文
posted @ 2011-04-10 21:41 spring yang 阅读(2370) 评论(5) 推荐(6) 编辑
摘要:概述 在软件系统中,由于应用环境的变化,常常需要将“一些现存的对象”放在新的环境中应用,但是新环境要求的接口是这些现存对象所不满足的。那么如何应对这种“迁移的变化”?如何既能利用现有对象的良好实现,同时又能满足新的应用环境所要求的接口?这就是本文要说的Adapter 模式。 意图 将一个类的接口转换成客户希望的另外一个接口。Adapter模式使得原本由于接口不兼容而不能一起工作的那些类可以一起工作... 阅读全文
posted @ 2011-04-08 00:34 spring yang 阅读(2937) 评论(7) 推荐(2) 编辑
摘要:概述 在软件系统中,有时候面临的产品类是动态变化的,而且这个产品类具有一定的等级结构。这时如果用工厂模式,则与产品类等级结构平行的工厂方法类也要随着这种变化而变化,显然不大合适。那么如何封装这种动态的变化?从而使依赖于这些易变对象的客户程序不随着产品类变化? 意图 在软件系统中,经常面临着“某些结构复杂的对象”的创建工作;由于需求的变化,这些对象经常面临着剧烈的变化,但是它们却拥有比较稳定一致的接... 阅读全文
posted @ 2011-04-06 22:55 spring yang 阅读(2146) 评论(0) 推荐(2) 编辑
摘要:概述Singleton模式要求一个类有且仅有一个实例,并且提供了一个全局的访问点。这就提出了一个问题:如何绕过常规的构造器,提供一种机制来保证一个类只有一个实例?客户程序在调用某一个类时,它是不会考虑这个类是否只能有一个实例等问题的,所以,这应该是类设计者的责任,而不是类使用者的责任。 从另一个角度来说,Singleton模式其实也是一种职责型模式。因为我们创建了一个对象,这个对象扮演了独一无二的角色,在这个单独的对象实例中,它集中了它所属类的所有权力,同时它也肩负了行使这种权力的职责! 意图 保证一个类仅有一个实例,并提供一个访问它的全局访问点。 模型图 逻辑模型图:物理模型图:<De 阅读全文
posted @ 2011-04-05 14:37 spring yang 阅读(2115) 评论(1) 推荐(1) 编辑
摘要:策略模式定义了一系列的算法,并将每一个算法封装起来,而且使它们还可以相互替换。策略模式让算法独立于使用它的客户而独立变化。(原文:The Strategy Pattern defines a family of algorithms,encapsulates each one,and makes them interchangeable. Strategy lets the algorithm vary independently from clients that use it.) Context(应用场景): 1、需要使用ConcreteStrategy提供的算法。 2、 内部维护一个St 阅读全文
posted @ 2011-04-02 00:07 spring yang 阅读(2312) 评论(2) 推荐(2) 编辑

点击右上角即可分享
微信分享提示