2006年8月18日

Flyweight享元(结构型模式)

摘要: 动机:  采用纯粹对象方案的问题在于大量细粒度的对象会很快充斥在系统中,从而带来很高的运行时代价--主要指内存需求方面的代价。  如何在避免大量细粒度对象问题的同时,让外部客户程序仍然能够透明地使用面向对象的方式来进行操作?  意图:  运用共享技术有效地支持大量细粒度的对象。  出自:《设计模式》GoFFlyweight模式的几个要点:  1、面向对象很好地解决了抽象性的问题,但是作为一个运行在... 阅读全文

posted @ 2006-08-18 13:56 walker 阅读(141) 评论(0) 推荐(0) 编辑

Facade外观(结构型模式)

摘要: 动机:  如何简化外部客户程序和系统间的交互接口?如何将外部客户程序的演化的内部子系统的变化之间的依赖相互解耦?意图:  为子系统中的一组接口提供一个一致的界面,Facade模式定义了一个高层接口,这个接口使得这一子系统更加容易使用。  出自:《设计模式》GoFFacade模式的几个要点:  1、从客户程序的角度来看,Facade模式不仅简化了整个组件系统的接口,同时对于组件内部与外部客户程序来说... 阅读全文

posted @ 2006-08-18 13:36 walker 阅读(170) 评论(0) 推荐(0) 编辑

Decorator装饰(结构型模式)

摘要: 动机:  如何使“对象功能的扩展”能够根据需要来动态地实现?同时避免“扩展功能的增多”带来的子类膨胀的问题?从而使得任何“功能扩展变化”所导致的影响降为最低?意图:  动态地给一个对象增加一些额外的职责。就增加功能而言,Decorator模式比生成子类更为灵活。  出自:《设计模式》GoFDecorator模式的几个要点:  ... 阅读全文

posted @ 2006-08-18 11:28 walker 阅读(158) 评论(0) 推荐(0) 编辑

Composite组合(结构型模式)

摘要: 动机:  客户代码过多地依赖于对象容器复杂的内部实现结构,对象容器内部实现结构(而非抽象接口)的变化将客户代码的频繁变化,带来了代码的维护性差、扩展性差等弊端。  如何将“客户代码与复杂的对象容器结构”解耦?让对象容器自己来实现自身的复杂结构,从而使得客户代码就像处理简单对象一样来处理复杂的对象容器?意图:  将对象组合成结构以表示“部分-整体”的层... 阅读全文

posted @ 2006-08-18 09:42 walker 阅读(170) 评论(0) 推荐(0) 编辑

导航