iamdll的专栏

5，state模式理解<br />作者：罗鹏 email: luopeng@ec.com.cn<br />主要是用于状态的变化，就象红绿灯一样<br />如何使用state模式<br />1，要一个状态管理类<br />2，状态接口<br />3，各种子状态实现状态接口<br /><br />State模式的效果 <br />1）它将与特定状态的行为局部化，并且将不同的行为分割开来 <br />2）它使得状态转化显式化 <br />3）State对象可以被共享 <b

概述Singleton模式要求一个类有且仅有一个实例，并且提供了一个全局的访问点。这就提出了一个问题：如何绕过常规的构造器，提供一种机制来保证一个类只有一个实例？客户程序在调用某一个类时，它是不会考虑这个类是否只能有一个实例等问题的，所以，这应该是类设计者的责任，而不是类使用者的责任。从另一个角度来说，Singleton模式其实也是一种职责型模式。因为我们创建了一个对象，这个对象扮演了独一无二的角色，在这个单独的对象实例中，它集中了它所属类的所有权力，同时它也肩负了行使这种权力的职责！意图保证一个类

概述<br />在软件开发系统中，客户程序经常会与复杂系统的内部子系统之间产生耦合，而导致客户程序随着子系统的变化而变化。那么如何简化客户程序与子系统之间的交互接口？如何将复杂系统的内部子系统与客户程序之间的依赖解耦？这就是要说的Façade 模式。<br /><br />意图为子系统中的一组接口提供一个一致的界面，Facade模式定义了一个高层接口，这个接口使得这一子系统更加容易使用。[GOF 《设计模式》]<br /><br />示意图门面模式没有一个一般化的类图描述，下面是一个示意性的对象图：图1

摘要：面向对象的思想很好地解决了抽象性的问题，一般也不会出现性能上的问题。但是在某些情况下，对象的数量可能会太多，从而导致了运行时的代价。那么我们如何去避免大量细粒度的对象，同时又不影响客户程序使用面向对象的方式进行操作？本文试图通过一个简单的字符处理的例子，运用重构的手段，一步步带你走进Flyweight模式，在这个过程中我们一同思考、探索、权衡，通过比较而得出好的实现方式，而不是给你最终的一个完美解决方案。主要内容：1． Flyweight模式解说2．.NET中的Flyweight模式3．Flyweig

摘要：结构型模式，顾名思义讨论的是类和对象的结构，它采用继承机制来组合接口或实现（类结构型模式），或者通过组合一些对象，从而实现新的功能（对象结构型模式）。这些结构型模式，它们在某些方面具有很大的相似性，仔细推敲，侧重点却各有不同。本文试图对这几种结构型模式做一个简单的小结。 主要内容1．结构型模式概述2．结构型模式区别与比较3．对变化的封装 结构型模式概述结构型模式，顾名思义讨论的是类和对象的结构，它采用继承机制来组合接口或实现（类结构型模式），或者通过组合一些对象，从而实现新的功能（对象结构型模

概述创建型模式，就是用来创建对象的模式，抽象了实例化的过程。它帮助一个系统独立于如何创建、组合和表示它的那些对象。本文对五种常用创建型模式进行了比较，通过一个游戏开发场景的例子来说该如何使用创建型模式。为什么需要创建型模式所有的创建型模式都有两个永恒的主旋律：第一，它们都将系统使用哪些具体类的信息封装起来；第二，它们隐藏了这些类的实例是如何被创建和组织的。外界对于这些对象只知道它们共同的接口，而不清楚其具体的实现细节。正因如此，创建型模式在创建什么（what），由谁（who）来创建，以及何时（when）创建

收藏——.NET设计模式系列之八Terrylee，2006年2月概述在软件系统中，由于应用环境的变化，常常需要将“一些现存的对象”放在新的环境中应用，但是新环境要求的接口是这些现存对象所不满足的。那么如何应对这种“迁移的变化”？如何既能利用现有对象的良好实现，同时又能满足新的应用环境所要求的接口？这就是本文要说的Adapter 模式。意图将一个类的接口转换成客户希望的另外一个接口。Adapter模式使得原本由于接口不兼容而不能一起工作的那些类可以一起工作。结构图图1 类的Adapter模式结构图图2 对象的

(第Ⅲ部分 结构型模式篇) 第9章 装饰模式（Decorator Pattern） 收藏——.NET设计模式系列之十Terrylee，2006年3月概述在软件系统中，有时候我们会使用继承来扩展对象的功能，但是由于继承为类型引入的静态特质，使得这种扩展方式缺乏灵活性；并且随着子类的增多（扩展功能的增多），各种子类的组合（扩展功能的组合）会导致更多子类的膨胀。如何使“对象功能的扩展”能够根据需要来动态地实现？同时避免“扩展功能的增多”带来的子类膨胀问题？从而使得任何“功能扩展变化”所导致

<br />杂元素的内部结构解耦。意图将对象组合成树形结构以表示“部分-整体”的层次结构。Composite模式使得用户对单个对象和组合对象的使用具有一致性。[GOF 《设计模式》]结构图图1 Composite模式结构图生活中的例子组合模式将对象组合成树形结构以表示"部分-整体"的层次结构。让用户一致地使用单个对象和组合对象。虽然例子抽象一些，但是算术表达式确实是组合的例子。算术表达式包括操作数、操作符和另一个操作数。操作数可以是数字，也可以是另一个表达式。这样，2+3和（2+3）+（4*6）都是合法的表

一.单一职责原则　　原文链接：http://blog.csdn.net/lovelion/article/details/7536542　　单一职责原则是最简单的面向对象设计原则，它用于控制类的粒度大小。单一职责原则定义如下： 单一职责原则(Single Responsibility Principle, SRP)：一个类只负责一个功能领域中的相应职责，或者可以定义为：就一个类而...

https://design-patterns.readthedocs.io/zh_CN/latest/软件模式是将模式的一般概念应用于软件开发领域，即软件开发的 总体指导思路或参照样板。软件模式并非仅限于设计模式，还包括 架构模式、分析模式和过程模式等，实际上，在软件生存期的每一 个阶段都存在着一些被认同的模式。本书使用图形和代码结合的方式来解析设计模式；每个模式都有相应的对象...

SourceMakingDesign PatternsDesign Patterns ReferenceDesign Patterns Video CourseAntiPatternsAntipatterns ReferenceAntiPatterns BookRefactoringRefactoring ReferenceUMLUML ReferenceUML CourseLog inContactDesign Patterns powered bySourcemaking.comSourcemaking

概述在软件构建过程中，我们需要为某些对象建立一种“通知依赖关系”——一个对象（目标对象）的状态发生改变，所有的依赖对象（观察者对象）都将得到通知。如果这样的依赖关系过于紧密，将使软件不能很好地抵御变化。使用面向对象技术，可以将这种依赖关系弱化，并形成一种稳定的依赖关系。从而实现软件体系结构的松耦合。意图定义对象间的一种一对多的依赖关系,当一个对象的状态发生改变时, 所有依赖于它的对象都得到通知并被自动更新。[GOF 《设计模式》]结构图图1 Observer模式结构图生活中的例子观察者定义了

<br /> 代理模式只是原来对象的一个替身，装饰模式是对原对象的功能增强，适配器模式是要改变原对象的接口<br /> <br /> <br />Structural patterns<br />Adapter 适配<br />allows classes with incompatible interfaces to work together bywrapping its own interface around that of an already existing class.

<br />前两天从微软网站上将李建忠的设计模式webcasts下载下来了，听了一下，尽管刚开始觉得他说话有点KA，但他的讲座确实让我对面向对象有一个重新的认识！下面是我的一些总结，来自他讲座的PPT。<br />一、对象是什么<br />从三个层次上来理解：<br />1、从概念层面讲，对象是某种拥有责任的抽象（对象是一个拥有某种功能的东西）<br />2、从规格层面讲，对象是一系列可以被其它对象使用的公共接口（这个东西提供了使用它所拥有的功能的途径）<br />3、从语言实现层面来看，对象封装了代码与数

概述在软件系统中，经常面临着“一系列相互依赖的对象”的创建工作；同时由于需求的变化，往往存在着更多系列对象的创建工作。如何应对这种变化？如何绕过常规的对象的创建方法（new），提供一种“封装机制”来避免客户程序和这种“多系列具体对象创建工作”的紧耦合？这就是我们要说的抽象工厂模式。意图提供一个创建一系列相关或相互依赖对象的接口，而无需指定它们具体的类。模型图逻辑模型：物理模型：生活中的例子抽象工厂的目的是要提供一个创建一系列相关或相互依赖对象的接口，而不需要指定它们具体的类。这种模式可以汽车制造厂所使用

概述在软件系统中，有时候面临着“一个复杂对象”的创建工作，其通常由各个部分的子对象用一定的算法构成；由于需求的变化，这个复杂对象的各个部分经常面临着剧烈的变化，但是将它们组合在一起的算法确相对稳定。如何应对这种变化？如何提供一种“封装机制”来隔离出“复杂对象的各个部分”的变化，从而保持系统中的“稳定构建算法”不随着需求改变而改变？这就是要说的建造者模式。本文通过现实生活中的买KFC的例子，用图解的方式来诠释建造者模式。意图将一个复杂的构建与其表示相分离，使得同样的构建过程可以创建不同的表示。模型

概述在软件系统中，经常面临着“某个对象”的创建工作，由于需求的变化，这个对象的具体实现经常面临着剧烈的变化，但是它却拥有比较稳定的接口。如何应对这种变化？提供一种封装机制来隔离出“这个易变对象”的变化，从而保持系统中“其它依赖该对象的对象”不随着需求的改变而改变？这就是要说的FactoryMethod模式了。意图定义一个用户创建对象的接口，让子类决定实例化哪一个类。Factory Method使一个类的实例化延迟到其子类。结构图生活中的例子工厂方法定义一个用于创建对象的接口，但是让子类决定实例化

概述在软件系统中，有时候面临的产品类是动态变化的，而且这个产品类具有一定的等级结构。这时如果用工厂模式，则与产品类等级结构平行的工厂方法类也要随着这种变化而变化，显然不大合适。那么如何封装这种动态的变化？从而使依赖于这些易变对象的客户程序不随着产品类变化？意图用原型实例指定创建对象的种类，并且通过拷贝这些原型创建新的对象。结构图Prototype模式结构图生活中的例子Prototype模式使用原型实例指定创建对象的种类。新产品的原型通常是先于全部产品建立的，这样的原型是被动的，并不参与复制它自己。一个细

概述在软件系统中，某些类型由于自身的逻辑，它具有两个或多个维度的变化，那么如何应对这种“多维度的变化”？如何利用面向对象的技术来使得该类型能够轻松的沿着多个方向进行变化，而又不引入额外的复杂度？这就要使用Bridge模式。意图将抽象部分与实现部分分离，使它们都可以独立的变化。[GOF 《设计模式》]结构图图1 Bridge模式结构图生活中的例子桥接模式将抽象部分与它的实现分离，使它们能够独立地变化。一个普通的开关控制的电灯、电风扇等等，都是桥接的例子。开关的目的是将设备打开或关闭。实际的开关可以是简单的双刀

摘要：在软件系统中，有些对象有时候由于跨越网络或者其他的障碍，而不能够或者不想直接访问另一个对象，如果直接访问会给系统带来不必要的复杂性，这时候可以在客户程序和目标对象之间增加一层中间层，让代理对象来代替目标对象打点一切。这就是本文要说的Proxy模式。 主要内容1．例说Proxy模式2．Proxy模式效果及实现要点…… 概述在软件系统中，有些对象有时候由于跨越网络或者其他的障碍，而不能够或者不想直接访问另一个对象，如果直接访问会给系统带来不必要的复杂性，这时候可以在客户程序和目标对象之间增加一层中间层，让

<br />摘要：Template Method模式是比较简单的设计模式之一，但它却是代码复用的一项基本的技术，在类库中尤其重要。 主要内容1．概述2．Template Method解说3．.NET中的Template Method模式4．适用性及实现要点 概述变化一直以来都是软件设计的永恒话题，在XP编程中提倡拥抱变化，积极应对。如何更好的去抓住变化点，应对变化？如何更好的提高代码复用？通过学习Template Method模式，您应该有一个新的认识。意图定义一个操作中的算法的骨架，而将一些步骤延迟到子类

概述在软件系统中，“行为请求者”与“行为实现者”通常呈现一种“紧耦合”。但在某些场合，比如要对行为进行“记录、撤销/重做、事务”等处理，这种无法抵御变化的紧耦合是不合适的。在这种情况下，如何将“行为请求者”与“行为实现者”解耦？将一组行为抽象为对象，可以实现二者之间的松耦合[李建忠]。这就是本文要说的Command模式。意图将一个请求封装为一个对象，从而使你可用不同的请求对客户进行参数化；对请求排队或记录请求日志，以及支持可撤消的操作。[GOF 《设计模式》]结构图Command模式结构图如下：

概述在面向对象的软件设计中，我们经常会遇到一类集合对象，这类集合对象的内部结构可能有着各种各样的实现，但是归结起来，无非有两点是需要我们去关心的：一是集合内部的数据存储结构，二是遍历集合内部的数据。面向对象设计原则中有一条是类的单一职责原则，所以我们要尽可能的去分解这些职责，用不同的类去承担不同的职责。Iterator模式就是分离了集合对象的遍历行为，抽象出一个迭代器类来负责，这样既可以做到不暴露集合的内部结构，又可让外部代码透明的访问集合内部的数据。意图提供一种方法顺序访问一个聚合对象中各

（1）从Function到Service一、从函数说起我是1993年学习电脑的。学习的开发语言有三种：汇编、C、DbaseIII。所以在我学习的时候，我并不了解面向对象的代码架构设计和代码编程实现。所以要从字面上来区分函数和函数之间的关系，主要就靠函数命名、放在同一个代码文件里、放在同一个代码目录文件夹里来区分他们之间的关联性。在当时函数时代，也没啥异常保护...