再创建Attendance.cs:
再创建Salary.cs:
再创建SalarySystem.cs:
最后再调用:
运行结果如下图:
效果及实现要点
1．Façade模式对客户屏蔽了子系统组件，因而减少了客户处理的对象的数目并使得子系统使用起来更加方便。
2．Façade模式实现了子系统与客户之间的松耦合关系，而子系统内部的功能组件往往是紧耦合的。松耦合关系使得子系统的组件变化不会影响到它的客户。
3．如果应用需要，它并不限制它们使用子系统类。因此你可以在系统易用性与通用性之间选择。
4．通过一个高层接口让子系统和客户端不发生直接关联，使客户端不受子系统变化的影响。
5．Facade不仅仅针对代码级别，在构架上，特别是WEB应用程序的构架上，Facade的应用非常普遍。
适用性
1．为一个复杂子系统提供一个简单接口。
2．提高子系统的独立性。
3．在层次化结构中，可以使用Facade模式定义系统中每一层的入口。
4．从代码角度来说， 如果你的程序有多个类是和一组其它接口发生关联的话可以考虑在其中加一个门面类型。
5．从应用角度来说， 如果子系统的接口是非常细的，调用方也有大量的逻辑来和这些接口发生关系，那么就可以考虑使用Facade把客户端与子系统的直接耦合关系进行化解。你可能会说，子系统改了门面不是照样改？的确是需要改，但是如果客户端本身的工作已经比较复杂，或者说可能有多个需要调用门面的地方，这个时候门面的好处就体现了。
优点
1．它对客户屏蔽子系统组件，因而减少了客户处理的对象的数目并使得子系统使用起来更加方便。
2．它实现了子系统与客户之间的松耦合关系，而子系统内部的功能组件往往是紧耦合的。
松耦合关系使得子系统的组件变化不会影响到它的客户。Facade模式有助于建立层次结构系统，也有助于对对象之间的依赖关系分层。Facade模式可以消除复杂的循环依赖关系。这一点在客户程序与子系统是分别实现的时候尤为重要。
在大型软件系统中降低编译依赖性至关重要。在子系统类改变时，希望尽量减少重编译工作以节省时间。用Facade可以降低编译依赖性，限制重要系统中较小的变化所需的重编译工作。Facade模式同样也有利于简化系统在不同平台之间的移植过程，因为编译一个子系统一般不需要编译所有其他的子系统。
3．如果应用需要，它并不限制它们使用子系统类。因此你可以在系统易用性和通用性之间加以选择。
总结
Façade模式注重的是简化接口，它更多的时候是从架构的层次去看整个系统，而并非单个类的层次。
作者: spring yang 发表于 2011-04-25 22:10 原文链接
组合模式有时候又叫做部分-整体模式，它使我们树型结构的问题中，模糊了简单元素和复杂元素的概念，客户程序可以向处理简单元素一样来处理复杂元素,从而使得客户程序与复杂元素的内部结构解耦。
描述Composite模式的最佳方式莫过于树形图。从抽象类或接口为根节点开始，然后生枝发芽，以形成树枝节点和叶结点。因此，Composite模式通常用来描述部分与整体之间的关系，而通过根节点对该结构的抽象，使得客户端可以将单元素节点与复合元素节点作为相同的对象来看待。
意图
将对象组合成树形结构以表示“部分-整体”的层次结构。Composite模式使得用户对单个对象和组合对象的使用具有一致性。[GOF 《设计模式》]
结构图
1．安全式的合成模式的结构
安全式的合成模式要求管理聚集的方法只出现在树枝构件类中，而不出现在树叶构件中。
这种形式涉及到三个角色：
- 抽象构件(Component)角色：这是一个抽象角色，它给参加组合的对象定义出公共的接口及其默认行为，可以用来管理所有的子对象。在安全式的合成模式里，构件角色并不是定义出管理子对象的方法，这一定义由树枝构件对象给出。
- 树叶构件（Leaf）角色：树叶对象是没有下级子对象的对象，定义出参加组合的原始对象的行为。
- 树枝构件（Composite）角色：代表参加组合的有下级子对象的对象。树枝对象给出所有的管理子对象的方法，如add（）、remove（）、getChild（）等。
2．透明式的合成模式结构
与安全式的合成模式不同的是，透明式的合成模式要求所有的具体构件类，不论树枝构件还是树叶构件，均符合一个固定的接口。
这种形式涉及到三个角色：
- 抽象构件（Component）角色：这是一个抽象角色，它给参加组合的对象规定一个接口，规范共有的接口及默认行为。
- 树叶构件（Leaf）角色：代表参加组合的树叶对象，定义出参加组合的原始对象的行为。树叶类会给出add（）、remove（）以及getChild（）之类的用来管理子类对对象的方法的平庸实现。
- 树枝构件（Composite）角色：代表参加组合的有子对象的对象，定义出这样的对象的行为。
生活中的例子
组合模式将对象组合成树形结构以表示"部分-整体"的层次结构。让用户一致地使用单个对象和组合对象。虽然例子抽象一些，但是算术表达式确实是组合的例子。算术表达式包括操作数、操作符和另一个操作数。操作数可以是数字，也可以是另一个表达式。这样，2+3和（2+3）+（4*6）都是合法的表达式。
图2 使用算术表达式例子的Composite模式对象图
示例用例图
建造房子正是一种组合模式,先把房子的结构建起来,再装上窗户和门就是一所房子了.来看用例图:
代码设计
先创建接口IBuild.cs:
再创建Build.cs:
再创建House.cs:
再创建Construct.cs:
再创建Window.cs:
再创建Door.cs:
最后调用:
结果如图:
效果及实现要点
1．Composite模式采用树形结构来实现普遍存在的对象容器，从而将“一对多”的关系转化“一对一”的关系，使得客户代码可以一致地处理对象和对象容器，无需关心处理的是单个的对象，还是组合的对象容器。
2．将“客户代码与复杂的对象容器结构”解耦是Composite模式的核心思想，解耦之后，客户代码将与纯粹的抽象接口——而非对象容器的复内部实现结构——发生依赖关系，从而更能“应对变化”。
3．Composite模式中，是将“Add和Remove等和对象容器相关的方法”定义在“表示抽象对象的Component类”中，还是将其定义在“表示对象容器的Composite类”中，是一个关乎“透明性”和“安全性”的两难问题，需要仔细权衡。这里有可能违背面向对象的“单一职责原则”，但是对于这种特殊结构，这又是必须付出的代价。ASP.NET控件的实现在这方面为我们提供了一个很好的示范。
4．Composite模式在具体实现中，可以让父对象中的子对象反向追溯；如果父对象有频繁的遍历需求，可使用缓存技巧来改善效率。
5．使用透明模式还是安全模式根据自己的需要定。
6．在某些情况下，树叶构件可以访问树枝构件获取一些信息。
7．如果树叶构件数量比较多，树枝构件频繁遍历子节点的话可以考虑进行缓存。
8．既然所有对象有了统一的接口，客户端应该针对抽象构件进行编程。
适用性
以下情况下适用Composite模式：
1．你想表示对象的部分-整体层次结构
2．你希望用户忽略组合对象与单个对象的不同，用户将统一地使用组合结构中的所有对象。
3．从代码角度来说，如果类型之间组成了层次结构，你希望使用统一的接口来管理每一个层次的类型的时候。
4．从应用角度来说，如果你希望把一对多的关系转化为一对一的关系的时候。
注意事项
1．明显的给出父对象的引用。在子对象里面给出父对象的引用，可以很容易的遍历所有父对象。有了这个引用，可以方便的应用责任链模式。
2．在通常的系统里，可以使用享元模式实现构件的共享，但是由于合成模式的对象经常要有对父对象的引用，因此共享不容易实现。
3．有时候系统需要遍历一个树枝结构的子构件很多次，这时候可以考虑把遍历子构件的结果暂时存储在父构件里面作为缓存。
4．关于使用什么数据类型来存储子对象的问题，在示意性的代码中使用了ArrayList，在实际系统中可以使用其它聚集或数组等。
5．客户端尽量不要直接调用树叶类中的方法，而是借助其父类（Component）的多态性完成调用，这样可以增加代码的复用性。
]]>
概述
在软件系统中，有时候我们会使用继承来扩展对象的功能，但是由于继承为类型引入的静态特质，使得这种扩展方式缺乏灵活性；并且随着子类的增多（扩展功能的增多），各种子类的组合（扩展功能的组合）会导致更多子类的膨胀。如何使“对象功能的扩展”能够根据需要来动态地实现？同时避免“扩展功能的增多”带来的子类膨胀问题？从而使得任何“功能扩展变化”所导致的影响将为最低？这就是本文要讲的Decorator模式。
一个场景是我们要为一个对象动态添加新的职责，这个职责并不修改原有的行为，而是在原有行为基础上添加新的功能，就好比装饰工人为一座新居的墙上涂抹上色彩缤纷的颜料一般。
意图
动态地给一个对象添加一些额外的职责。就增加功能来说，Decorator模式相比生成子类更为灵活。[GOF 《设计模式》]
<Design Pattern>结构图
图1 Decorator模式结构图
在装饰模式中的各个角色有：
- 抽象构件（Component）角色：给出一个抽象接口，以规范准备接收附加责任的对象。
- 具体构件（Concrete Component）角色：定义一个将要接收附加责任的类。
- 装饰（Decorator）角色：持有一个构件（Component）对象的实例，并定义一个与抽象构件接口一致的接口。
- 具体装饰（Concrete Decorator）角色：负责给构件对象"贴上"附加的责任。
生活中的例子
装饰模式动态地给一个对象添加额外的职责。不论一幅画有没有画框都可以挂在墙上，但是通常都是有画框的，并且实际上是画框被挂在墙上。在挂在墙上之前，画可以被蒙上玻璃，装到框子里；这时画、玻璃和画框形成了一个物体。
图2 使用有画框的画作为例子的装饰模式对象图
示例用例图
在超市里,平常节日都有优惠活动,不同节日有不同优惠活动,我们用装饰模式写一个超市节日打折的例子,用例图如下:
代码设计
先创建SuperMarket.cs:
再创建Decorator.cs:
再创建WalMart .cs:
再创建SpringFestival.cs:
最后再调用:
结果如下图:
效果及实现要点
1．Component类在Decorator模式中充当抽象接口的角色，不应该去实现具体的行为。而且Decorator类对于Component类应该透明，换言之Component类无需知道Decorator类，Decorator类是从外部来扩展Component类的功能。
2．Decorator类在接口上表现为is-a Component的继承关系，即Decorator类继承了Component类所具有的接口。但在实现上又表现为has-a Component的组合关系，即Decorator类又使用了另外一个Component类。我们可以使用一个或者多个Decorator对象来“装饰”一个Component对象，且装饰后的对象仍然是一个Component对象。
3．Decortor模式并非解决“多子类衍生的多继承”问题，Decorator模式的应用要点在于解决“主体类在多个方向上的扩展功能”——是为“装饰”的含义。
4．对于Decorator模式在实际中的运用可以很灵活。如果只有一个ConcreteComponent类而没有抽象的Component类，那么Decorator类可以是ConcreteComponent的一个子类。
如果只有一个ConcreteDecorator类，那么就没有必要建立一个单独的Decorator类，而可以把Decorator和ConcreteDecorator的责任合并成一个类。
5．Decorator模式的优点是提供了比继承更加灵活的扩展，通过使用不同的具体装饰类以及这些装饰类的排列组合，可以创造出很多不同行为的组合。
6．由于使用装饰模式，可以比使用继承关系需要较少数目的类。使用较少的类，当然使设计比较易于进行。但是，在另一方面，使用装饰模式会产生比使用继承关系更多的对象。更多的对象会使得查错变得困难，特别是这些对象看上去都很相像。
7．让装饰角色还继承抽象构件角色也是装饰模式最大的特点，目的就是给抽象构件增加职责，对外表现为装饰后的构件。
8．让装饰角色拥有构件角色实例的目的就是让构件能被多个装饰对象来装饰。
9．在具体应用中可以灵活一点，不一定要有抽象构件和装饰角色。但是，装饰对象继承装饰对象并且拥有它实例的两大特点需要体现。
10．透明装饰一般通过在基类方法前后进行扩充实现，半透明装饰一般通过新的接口实现。
适用性
1．需要扩展一个类的功能，或给一个类增加附加责任。
2．需要动态地给一个对象增加功能，这些功能可以再动态地撤销。
3．需要增加由一些基本功能的排列组合而产生的非常大量的功能，从而使继承关系变得不现实。
4．从代码角度来说，如果你觉得由于功能的交叉扩展不会导致非常多的子类或者非常多的继承层次的话可以考虑装饰模式。
5．从应用角度来说，如果你希望动态给类赋予或撤销一些职责，并且可以任意排列组合这些职责的话可以使用装饰模式。
优点
1．装饰模式与继承关系的目的都是要扩展对象的功能，但是装饰模式可以提供比继承更多的灵活性。
2．通过使用不同的具体装饰类以及这些装饰类的排列组合，设计师可以创造出很多不同行为的组合。
3．这种比继承更加灵活机动的特性，也同时意味着装饰模式比继承更加易于出错。
缺点
1．由于使用装饰模式，可以比使用继承关系需要较少数目的类。使用较少的类，当然使设计比较易于进行。但是，在另一方面，使用装饰模式会产生比使用继承关系更多的对象。更多的对象会使得查错变得困难，特别是这些对象看上去都很相像。
注意点
1．一个装饰类的接口必须与被装饰类的接口相容。
2．尽量保持Component作为一个"轻"类，不要把太多的逻辑和状态放在Component类里。
3．如果只有一个ConcreteComponent类而没有抽象的Component类（接口），那么Decorator类经常可以是ConcreteComponent的一个子类。如下图所示：
4．如果只有一个ConcreteDecorator类，那么就没有必要建立一个单独的Decorator类，而可以把Decorator和ConcreteDecorator的责任合并成一个类。
总结
Decorator模式采用对象组合而非继承的手法，实现了在运行时动态的扩展对象功能的能力，而且可以根据需要扩展多个功能，避免了单独使用继承带来的“灵活性差”和“多子类衍生问题”。同时它很好地符合面向对象设计原则中“优先使用对象组合而非继承”和“开放-封闭”原则。
作者: spring yang 发表于 2011-04-23 00:24 原文链接
]]>
概述
在软件系统中，某些类型由于自身的逻辑，它具有两个或多个维度的变化，那么如何应对这种“多维度的变化”？如何利用面向对象的技术来使得该类型能够轻松的沿着多个方向进行变化，而又不引入额外的复杂度？这就要使用Bridge模式。
桥梁模式是一个非常有用的模式，也是比较复杂的一个模式。熟悉这个模式对于理解面向对象的设计原则，包括"开－闭"原则(OCP)以及组合/聚合复用原则(CARP)都很有帮助。理解好这两个原则，有助于形成正确的设计思想和培养良好的设计风格。
意图
将抽象部分与实现部分分离，使它们都可以独立的变化。[GOF 《设计模式》],这里的抽象和实现并不一定是同一层次的概念，例如数据库操作可以归结为“增加、删除和修改”。很多业务过程都是通过对数据库的操作实现的，例如“库存管理”中的“入库”，这个业务动作的软件实现可以描述为“在库存表中增加一条记录”，而“入库”和“插入记录”处于不同的业务层次。
<Design Pattern>结构图
图1 Bridge模式结构图
可以看出，这个系统含有两个等级结构，也就是：
- 由抽象化角色和修正抽象化角色组成的抽象化等级结构。
- 由实现化角色和两个具体实现化角色所组成的实现化等级结构。
桥梁模式所涉及的角色有：
- 抽象化(Abstraction)角色：抽象化给出的定义，并保存一个对实现化对象的引用。
- 修正抽象化(Refined Abstraction)角色：扩展抽象化角色，改变和修正父类对抽象化的定义。
- 实现化(Implementor)角色：这个角色给出实现化角色的接口，但不给出具体的实现。必须指出的是，这个接口不一定和抽象化角色的接口定义相同，实际上，这两个接口可以非常不一样。实现化角色应当只给出底层操作，而抽象化角色应当只给出基于底层操作的更高一层的操作。
- 具体实现化(Concrete Implementor)角色：这个角色给出实现化角色接口的具体实现。
生活中的例子
桥接模式将抽象部分与它的实现分离，使它们能够独立地变化。一个普通的开关控制的电灯、电风扇等等，都是桥接的例子。开关的目的是将设备打开或关闭。实际的开关可以是简单的双刀拉链开关，也可以是调光开关。
图2 使用电子开关例子的桥接对象图
形象比喻
小时候我们都用蜡笔画画，一盒蜡笔12种颜色。一开始我都是用最小号的蜡笔画个太阳公公、月亮婆婆足够了。后来开始画一些抽象派的作品，就得换中号的了，要不然画个背景都要描半天，好一盒中号的也是12种颜色。再后来我开始转向豪放派，中号就有些捉襟见肘了，只好换大号的了，好一盒大号的也只有12种颜色。你看，像我这样不太出名的画家就需要36种画笔，哇，太麻烦了。但是据我观察，另一些比我出名的画家倒是没有这么多笔，他们只有几把刷子和一些颜料，这样就解决了蜡笔的“种类爆炸”问题。如下图所示:
我要用36种蜡笔 
齐白石老先生只用3种毛笔和12种颜料
示例用例图
控制程序开和关,与哪种类型的控制,如:电视,灯等等.正好符合桥接模式,用例图如下:
代码设计
先创建CntrlControl.cs:
再创建Lamp.cs:
再创建Television.cs:
再创建ControlCenter.cs:
再创建LampControl.cs:
再创建TVControl.cs:
最后再调用:
运行结果如下图:
效果及实现要点
1．Bridge模式使用“对象间的组合关系”解耦了抽象和实现之间固有的绑定关系，使得抽象和实现可以沿着各自的维度来变化。
2．所谓抽象和实现沿着各自维度的变化，即“子类化”它们，得到各个子类之后，便可以任意它们，从而获得不同平台上的不同型号。
3．Bridge模式有时候类似于多继承方案，但是多继承方案往往违背了类的单一职责原则（即一个类只有一个变化的原因），复用性比较差。Bridge模式是比多继承方案更好的解决方法。
4．Bridge模式的应用一般在“两个非常强的变化维度”，有时候即使有两个变化的维度，但是某个方向的变化维度并不剧烈——换言之两个变化不会导致纵横交错的结果，并不一定要使用Bridge模式。
5．选择合适的类型作为抽象化角色（第一维度）。
6．抽象化角色和实现化角色通过组合进行关联。
7．抽象和实现不绑定，允许客户端作切换。
适用性
在以下的情况下应当使用桥梁模式：
1．如果一个系统需要在构件的抽象化角色和具体化角色之间增加更多的灵活性，避免在两个层次之间建立静态的联系。
2．设计要求实现化角色的任何改变不应当影响客户端，或者说实现化角色的改变对客户端是完全透明的。
3．一个构件有多于一个的抽象化角色和实现化角色，系统需要它们之间进行动态耦合。
4．虽然在系统中使用继承是没有问题的，但是由于抽象化角色和具体化角色需要独立变化，设计要求需要独立管理这两者。
5．从代码角度来说，如果类型的继承是处于2个目的（违背单一职责原则）的话可以使用Bridge模式避免过多的子类。
6．从应用角度来说， 如果应用会在多个维度上进行变化，客户端希望两个维度（场景、游戏模式）的对象相对独立，动态耦合（客户端决定哪个场景和哪个游戏模式耦合）的时候可以考虑Bridge模式。
总结
Bridge模式是一个非常有用的模式，也非常复杂，它很好的符合了开放-封闭原则和优先使用对象，而不是继承这两个面向对象原则。
]]>
概述
在软件构建过程中，我们需要为某些对象建立一种“通知依赖关系” ——一个对象（目标对象）的状态发生改变，所有的依赖对象（观察者对象）都将得到通知。如果这样的依赖关系过于紧密，将使软件不能很好地抵御变化。使用面向对象技术，可以将这种依赖关系弱化，并形成一种稳定的依赖关系。从而实现软件体系结构的松耦合。
一个软件系统常常要求在某一个对象的状态发生变化的时候，某些其它的对象做出相应的改变。做到这一点的设计方案有很多，但是为了使系统能够易于复用，应该选择低耦合度的设计方案。减少对象之间的耦合有利于系统的复用，但是同时设计师需要使这些低耦合度的对象之间能够维持行动的协调一致，保证高度的协作（Collaboration）。观察者模式是满足这一要求的各种设计方案中最重要的一种。
意图
定义对象间的一种一对多的依赖关系,当一个对象的状态发生改变时, 所有依赖于它的对象都得到通知并被自动更新。[GOF 《设计模式》]
<Design Pattern>结构图
图1 Observer模式结构图
角色说明:
Subject（被观察的对象接口）
规定ConcreteSubject的统一接口；
每个Subject可以有多个Observer；
ConcreteSubject（具体被观察对象）
维护对所有具体观察者的引用的列表；
状态发生变化时会发送通知给所有注册的观察者。
Observer（观察者接口）
规定ConcreteObserver的统一接口；
定义了一个update()方法，在被观察对象状态改变时会被调用。
ConcreteObserver（具体观察者）
维护一个对ConcreteSubject的引用；
特定状态与ConcreteSubject同步；
实现Observer接口，通过update()方法接收ConcreteSubject的通知。
生活中的例子
观察者定义了对象间一对多的关系，当一个对象的状态变化时，所有依赖它的对象都得到通知并且自动地更新。拍卖演示了这种模式。每个投标人都有一个标有数字的牌子用于出价。拍卖师开始拍卖时，他观察是否有牌子举起出价。每次接受一个新的出价都改变了拍卖的当前价格，并且广播给所有的投标人进行新的出价。
图2 使用拍卖例子的观察者模式
示例用例图:
十字路口的红绿灯,行人和司机都看红绿灯的变化来行动,司机看到向左转的指示灯和行人看到绿灯过马路这一情景,正好符合我们的观察者模式,司机(Drive)和行人(Pedestrian)是具体观察者而指示灯(PilotLamp)是观察者接口和红绿灯(TrafficLight)具体被观察对象,先看用例图:
代码设计:
先创建PilotLamp.cs:
再创建DelegateEvent.cs:
再创建TrafficLight.cs:
再创建Driver.cs:
再创建Pedestrian.cs:
最后再调用:
输出时选控制台应用程序如图:
结果如下图:
效果及实现要点
1．使用面向对象的抽象，Observer模式使得我们可以独立地改变目标与观察者，从而使二者之间的依赖关系达到松耦合。
2．目标发送通知时，无需指定观察者，通知（可以携带通知信息作为参数）会自动传播。观察者自己决定是否需要订阅通知。目标对象对此一无所知。
3．在C#中的Event。委托充当了抽象的Observer接口，而提供事件的对象充当了目标对象，委托是比抽象Observer接口更为松耦合的设计。
4．抽象主体角色公开了自身的事件，可以给任意观察者订阅。
5． 抽象观察者角色定义了统一的处理行为，在C#中使用事件-代理模式的话，统一的处理行为并不这么重要，有的时候甚至还会限制灵活性。由于本例的特殊原因，并没有从这个接口中得益。
6．响应方法订阅代理事件的操作可以在观察者中定义也可以在外部定义，根据自己的需求决定，放在外部定义灵活性更高。
7． 具体观察者往往只需要实现响应方法即可。
8．可以有多个主体角色、多个观察者角色交错，也可以一个类型是两个角色，主体也可以提供多个事件。从应用上来说观察者模式变化是非常多的。
适用性
1．当一个抽象模型有两个方面, 其中一个方面依赖于另一方面。将这二者封装在独立的对象中以使它们可以各自独立地改变和复用。
2．当对一个对象的改变需要同时改变其它对象, 而不知道具体有多少对象有待改变。
3．当一个对象必须通知其它对象，而它又不能假定其它对象是谁。换言之, 你不希望这些对象是紧密耦合的。
4．一个对象的行为引发其它多个对象的行为。前者成为主体，后者称为观察者。
5．为了降低耦合，不希望主体直接调用观察者的方法，而是采用动态订阅主体事件的方式来进行自动的连锁响应行为。
6．为了增加灵活性，希望动态调整订阅主体事件的观察者，或者希望动态调整观察者订阅主体的事件。
优点
1．观察者模式在被观察者和观察者之间建立一个抽象的耦合。被观察者角色所知道的只是一个具体现察者聚集，每一个具体现察者都符合一个抽象观察者的接口。被观察者并不认识任何一个具体观察者，它只知道它们都有一个共同的接口。由于被观察者和观察者没有紧密地耦合在一起，因此它们可以属于不同的抽象化层次。
2．观察者模式支持广播通信。被观察者会向所有的登记过的观察者发出通知。
缺点
1．如果一个被观察者对象有很多直接和间接的观察者的话，将所有的观察者都通知到会花费很多时间。
2．如果在被观察者之间有循环依赖的话，被观察者会触发它们之间进行循环调用，导致系统崩溃。在使用观察考模式时要特别注意这一点。
3．如果对观察者的通知是通过另外的线程进行异步投递的话，系统必须保证投递是以自恰的方式进行的。
4．虽然观察者模式可以随时使观察者知道所观察的对象发生了变化，但是观察者模式没有相应的机制使观察者知道所观察的对象是怎么发生变化的。
总结
1．通过Observer模式，把一对多对象之间的通知依赖关系的变得更为松散，大大地提高了程序的可维护性和可扩展性，也很好的符合了开放-封闭原则。
2．由于这种灵活性，在观察者订阅事件的时候需要考虑是否会出现破坏行为？是否会出现无限循环或死锁等问题？观察者响应的时候是否会影响其它观察者？
3．对于观察者数量很多的时候使用观察者模式并不适合，可能会造成性能问题。
4．在不能采用事件-代理方式完成观察者模式的情况下（比如跨网络应用等）可以考虑采用传统的观察者模式。
概述
在面向对象的软件设计中，我们经常会遇到一类集合对象，这类集合对象的内部结构可能有着各种各样的实现，但是归结起来，无非有两点是需要我们去关心的：一是集合内部的数据存储结构，二是遍历集合内部的数据。面向对象设计原则中有一条是类的单一职责原则，所以我们要尽可能的去分解这些职责，用不同的类去承担不同的职责。Iterator模式就是分离了集合对象的遍历行为，抽象出一个迭代器类来负责，这样既可以做到不暴露集合的内部结构，又可让外部代码透明的访问集合内部的数据。
为什么要写
但现在C#的Foreach in己经替代了迭代器模式的功能,但是作为学习设计模式来说,还是很有好处的.
意图
提供一种方法顺序访问一个聚合对象中各个元素, 而又不需暴露该对象的内部表示。[GOF 《设计模式》]
结构图
＜Design Pattern＞Iterator模式结构图如下：
图1 Iterator模式结构图
迭代器模式由以下角色组成：
1.迭代器角色（Iterator）：迭代器角色负责定义访问和遍历元素的接口。
2.具体迭代器角色（Concrete Iterator）：具体迭代器角色要实现迭代器接口，并要记录遍历中的当前位置。
3.容器角色（Container）：容器角色负责提供创建具体迭代器角色的接口。
4.具体容器角色（Concrete Container）：具体容器角色实现创建具体迭代器角色的接口——这个具体迭代器角色于该容器的结构相关。
生活中的例子
迭代器提供一种方法顺序访问一个集合对象中各个元素，而又不需要暴露该对象的内部表示。在早期的电视机中，一个拨盘用来改变频道。当改变频道时，需要手工转动拨盘移过每一个频道，而不论这个频道是否有信号。现在的电视机，使用[后一个]和[前一个]按钮。当按下[后一个]按钮时，将切换到下一个预置的频道。想象一下在陌生的城市中的旅店中看电视。当改变频道时，重要的不是几频道，而是节目内容。如果对一个频道的节目不感兴趣，那么可以换下一个频道，而不需要知道它是几频道。
图2 使用选频器做例子的Iterator模式对象图
示例用例图：
超市顾客排队结帐，收银员一个一个顺序的结帐，正好符合我们的迭代器模式，以下是用例图：
代码设计：
先创建Cashier.cs:
再创建IConsumer.cs:
再创建Consumer.cs:
再创建CLoseAccount.cs:
最后调用:
结果如下图:
效果及实现要点
1．迭代抽象：访问一个聚合对象的内容而无需暴露它的内部表示。
2．迭代多态：为遍历不同的集合结构提供一个统一的接口，从而支持同样的算法在不同的集合结构上进行操作。
3．迭代器的健壮性考虑：遍历的同时更改迭代器所在的集合结构，会导致问题。
适用性
1．访问一个聚合对象的内容而无需暴露它的内部表示。
2．支持对聚合对象的多种遍历。
3．为遍历不同的聚合结构提供一个统一的接口(即, 支持多态迭代)。
优点：
1．支持以不同的方式遍历一个容器角色。根据实现方式的不同，效果上会有差别。
2．简化了容器的接口。但是在IList中为了提高可扩展性，容器还是提供了遍历的接口。
3．对同一个容器对象，可以同时进行多个遍历。因为遍历状态是保存在每一个迭代器对象中的。
总结
Iterator模式就是分离了集合对象的遍历行为，抽象出一个迭代器类来负责，这样既可以做到不暴露集合的内部结构，又可让外部代码透明的访问集合内部的数据。
概述
在软件系统中，有时候面临着“一个复杂对象”的创建工作，其通常由各个部分的子对象用一定的算法构成；由于需求的变化，这个复杂对象的各个部分经常面临着剧烈的变化，但是将它们组合在一起的算法确相对稳定。如何应对这种变化？如何提供一种“封装机制”来隔离出“复杂对象的各个部分”的变化，从而保持系统中的“稳定构建算法”不随着需求改变而改变？这就是要说的建造者模式。
本文通过现实汽车生产中的例子，来诠释建造者模式。
意图
将一个复杂的构建与其表示相分离，使得同样的构建过程可以创建不同的表示。
<Design Pattern>Builder模型图
通俗讲解：Builder模式的理解
建造者（Builder）角色：给出一个抽象接口，以规范产品对象的各个组成成分的建造。一般而言，此接口独立于应用程序的商业逻辑。模式中直接创建产品对象的是具体建造者（ConcreteBuilder）角色。具体建造者类必须实现这个接口所要求的方法：一个是建造方法，另一个是结果返还方法。
具体建造者（Concrete Builder）角色：担任这个角色的是于应用程序紧密相关的类，它们在应用程序调用下创建产品实例。这个角色主要完成的任务包括：
- 实现Builder角色提供的接口，一步一步完成创建产品实例的过程。
- 在建造过程完成后，提供产品的实例。
指导者（Director）角色：担任这个角色的类调用具体建造者角色以创建产品对象。导演者并没有产品类的具体知识，真正拥有产品类的具体知识的是具体建造者对象。
产品（Product）角色：产品便是建造中的复杂对象。
指导者角色是于客户端打交道的角色。导演者角色将客户端创建产品的请求划分为对各个零件的建造请求，再将这些请求委派给具体建造者角色。具体建造者角色是做具体建造工作的，但却不为客户端所知。
简单地说，就好象我要一座房子住，可是我不知道怎么盖（简单的砌墙，层次较低），也不知道怎么样设计（建几个房间，几个门好看，层次较高）， 于是我需要找一帮民工，他们会砌墙，还得找个设计师，他知道怎么设计，我还要确保民工听设计师的领导，而设计师本身也不干活，光是下命令，这里砌一堵墙，这里砌一扇门，这样民工开始建设，最后，我可以向民工要房子了。在这个过程中，设计师是什么也没有，除了他在脑子里的设计和命令，所以要房子也是跟民工要，记住了！
就象国内好多企业上erp一样，上erp，首先得找软件公司呀，找到软件公司后，软件公司说，我只知道怎么写软件，就知道怎么实现，不清楚整个erp的流程。好，那我们还得找一个咨询公司，好，找到德勤了，德勤说好，我要软件怎么做，软件公司怎么做，我就能保证软件能为你们提供erp系统了。
示例用例图:
汽车的生产其实可以看作是一个建造者模式,大众生产Audi和Satana两种轿车,我们用例设计如下:
代码设计:
先创建 Car.cs:
然后创建BuildCar.cs:
再创建Audi.cs:
再创建Satana.cs:
再创建GenerateCar.cs:
最后再调用:
结果如下图:
实现要点
1、建造者模式主要用于“分步骤构建一个复杂的对象”，在这其中“分步骤”是一个稳定的算法，而复杂对象的各个部分则经常变化。
2、产品不需要抽象类，特别是由于创建对象的算法复杂而导致使用此模式的情况下或者此模式应用于产品的生成过程，其最终结果可能差异很大，不大可能提炼出一个抽象产品类。
3、创建者中的创建子部件的接口方法不是抽象方法而是空方法，不进行任何操作，具体的创建者只需要覆盖需要的方法就可以，但是这也不是绝对的，特别是类似文本转换这种情况下，缺省的方法将输入原封不动的输出是合理的缺省操作。
4、前面我们说过的抽象工厂模式（Abtract Factory）解决“系列对象”的需求变化，Builder模式解决“对象部分”的需求变化，建造者模式常和组合模式（Composite Pattern）结合使用。
5、对象的构建过程由指导者完成，具体的组成由具体建造者完成，表示与构建分离。
6、 建造者和指导者是建造者模式的关键点，如果进行合并或省略就可能会转变到模版方法模式。
7、如果对象的建造步骤是简单的，并且产品拥有一致的接口可以转而使用工厂模式。
效果
1、建造者模式的使用使得产品的内部表象可以独立的变化。使用建造者模式可以使客户端不必知道产品内部组成的细节。
2、每一个Builder都相对独立，而与其它的Builder无关。
3、可使对构造过程更加精细控制。
4、将构建代码和表示代码分开。
5、建造者模式的缺点在于难于应付“分步骤构建算法”的需求变动。
适用性
以下情况应当使用建造者模式：
1、需要生成的产品对象有复杂的内部结构。
2、需要生成的产品对象的属性相互依赖，建造者模式可以强迫生成顺序。
3、 在对象创建过程中会使用到系统中的一些其它对象，这些对象在产品对象的创建过程中不易得到。
4 、从代码角度来说， 如果你希望分离复杂类型构建规则和类型内部组成，或者希望把相同的构建过程用于构建不同类型的时候可以考虑使用建造者模式。
5、从应用角度来说， 如果你希望解耦产品的创建过程和产品的具体配件，或者你希望为所有产品的创建复用一套稳定并且复杂的逻辑的时候可以考虑使用建造者模式。
总结
1、建造者模式的实质是解耦组装过程和创建具体部件，使得我们不用去关心每个部件是如何组装的。
2、返回产品的方法是否必须，是否一定要在抽象建造者中有接口根据实际情况而定。如果它们有统一的接口可以在抽象建造者中体现这个抽象方法，如果没有统一的接口（比如，生产毫无关联的产品）则可以在具体建造者中各自实现这个方法，如果创建的产品是一种产品，那么甚至可以省略返回产品的接口（本文的例子就是这样）。
概述
在软件系统中，“行为请求者”与“行为实现者”通常呈现一种“紧耦合”。但在某些场合，比如要对行为进行“记录、撤销/重做、事务”等处理，这种无法抵御变化的紧耦合是不合适的。在这种情况下，如何将“行为请求者”与“行为实现者”解耦？将一组行为抽象为对象，可以实现二者之间的松耦合。这就是本文要说的Command模式。
意图
将一个请求封装为一个对象，从而使你可用不同的请求对客户进行参数化；对请求排队或记录请求日志，以及支持可撤消的操作。[GOF 《设计模式》]
结构图
<Design Pattern>Command模式结构图如下：
图1 Command模式结构图
西游记中例子:玉帝传美猴王上天
命令模式不是新的发明，在美猴王大闹天宫之前就有了。那时玉帝命令太白金星召美猴王上天："金星径入(水帘洞)当中，面南立定道：'我是西方太白金星，奉玉帝招安圣旨，下界请你上大，拜受仙录。'"玉帝是系统的客户端，太白金星是命令的发出者，猴王是命令的接收者，圣旨就是命令。玉帝的这一道命令就是要求猴王到上界报到。玉帝只管发出命令，而不管命令是怎样传达到美猴王的。太白金星负责将圣旨传到，可是美猴王怎么执行圣旨、何时执行圣旨是美猴王自己的事。果不然，个久美猴王就大闹了天宫。
这个模拟系统的设计如下：
生活中的例子
Command模式将一个请求封装为一个对象，从而使你可以使用不同的请求对客户进行参数化。用餐时的账单是Command模式的一个例子。服务员接受顾客的点单，把它记在账单上封装。这个点单被排队等待烹饪。注意这里的"账单"是不依赖于菜单的，它可以被不同的顾客使用，因此它可以添入不同的点单项目。
图2 使用用餐例子的Command模式对象图
示例用例结构图:
手机操作系统包括开机、关机、打电话、挂电话、发短信和删除短信功能，其实这就是一个命令模式，类结构示意图如下：
先创建接口ICommand.cs:
再创建SystemCommand.cs:
再创建MobileSystem.cs:
再创建StartUp.cs:
再创建Call.cs:
再创建SMS.cs:
再创建MobileServer.cs:
最后再调用:
看结果:
效果及实现要点
1．Command模式的根本目的在于将“行为请求者”与“行为实现者”解耦，在面向对象语言中，常见的实现手段是“将行为抽象为对象”。
2．实现Command接口的具体命令对象ConcreteCommand有时候根据需要可能会保存一些额外的状态信息。
3．通过使用Compmosite模式，可以将多个命令封装为一个“复合命令”MacroCommand。
4．Command模式与C#中的Delegate有些类似。但两者定义行为接口的规范有所区别：Command以面向对象中的“接口-实现”来定义行为接口规范，更严格，更符合抽象原则；Delegate以函数签名来定义行为接口规范，更灵活，但抽象能力比较弱。
5．使用Command模式会导致某些系统有过多的具体命令类。某些系统可能需要几十个，几百个甚至几千个具体命令类，这会使命令模式在这样的系统里变得不实际。
6.从活动序列上来说通常是这样的一个过程：客户端指定一个命令的接受者；客户端创建一个具体的命令对象，并且告知接受者；客户端通过调用者对象来执行具体命令；调用者对象在合适的时候发出命令的执行指令；具体命令对象调用命令接受者的方法来落实命令的执行。
7.Command模式从结构上说变化非常多，要点就是一个抽象命令接口。抽象命令接口包含两个含义，一是把方法提升到类的层次，二是使用统一的接口来执行命令。
8.有了前面说的这个前提，我们才可以在调用者角色中做很多事情。比如，延迟命令的执行、为执行的命令记录日志、撤销执行的命令等等。
9.在应用的过程中可以省略一些不重要的角色。比如，如果只有一个执行者或者执行的逻辑非常简单的话，可以把执行的逻辑合并到具体命令角色中；如果我们并不需要使用调用者来做额外的功能，仅仅是希望通过命令模式来解除客户端和接受者之间耦合的话可以省略调用者角色。
10.如果需要实现类似于宏命令的命令组可以使用组合模式来封装具体命令。
11. 如果需要实现undo操作，那么命令接受者通常也需要公开undo的接口。在应用中，undo操作往往不是调用一下undo方法这么简单，因为一个操作执行后所改变的环境往往是复杂的。
适用性
在下面的情况下应当考虑使用命令模式：
1．使用命令模式作为"CallBack"在面向对象系统中的替代。"CallBack"讲的便是先将一个函数登记上，然后在以后调用此函数。
2．需要在不同的时间指定请求、将请求排队。一个命令对象和原先的请求发出者可以有不同的生命期。换言之，原先的请求发出者可能已经不在了，而命令对象本身仍然是活动的。这时命令的接收者可以是在本地，也可以在网络的另外一个地址。命令对象可以在串形化之后传送到另外一台机器上去。
3．系统需要支持命令的撤消(undo)。命令对象可以把状态存储起来，等到客户端需要撤销命令所产生的效果时，可以调用undo()方法，把命令所产生的效果撤销掉。命令对象还可以提供redo()方法，以供客户端在需要时，再重新实施命令效果。
4．如果一个系统要将系统中所有的数据更新到日志里，以便在系统崩溃时，可以根据日志里读回所有的数据更新命令，重新调用Execute()方法一条一条执行这些命令，从而恢复系统在崩溃前所做的数据更新。
5.命令的发起人和命令的接收人有不同的生命周期。比如，下遗嘱的这种行为就是命令模式，一般来说遗嘱执行的时候命令的发起人已经死亡，命令是否得到有效的执行需要靠律师去做的。
6.希望能让命令具有对象的性质。比如，希望命令能保存以实现撤销；希望命令能保存以实现队列化操作。撤销的行为在GUI中非常常见，队列化命令在网络操作中也非常常见。
7.把命令提升到类的层次后我们对类行为的扩展就会灵活很多，别的不说，我们可以把一些创建型模式和结构型模式与命令模式结合使用。
总结
1.Command模式是非常简单而又优雅的一种设计模式，它的根本目的在于将“行为请求者”与“行为实现者”解耦。
2. 不要被命令模式复杂的结构所迷惑，如果你不能理解的话请思考这句话“把方法提升到类的层次的好处也就是命令模式的好处”。
3.和把状态或算法提到类的层次的状态模式或策略模式相比，命令模式可能会产生更多的类或对象。
]]>
概述
意图
状态模式主要解决的是当控制一个对象状态装换的条件表达式过于复杂时的情况。把状态的判断逻辑转移到表示不同状态的一系列类中，可以把复杂的判断逻辑简单化。
当一个对象行为取决于它的状态，并且它必须在运行时刻根据状态改变它的行为时，就可以考虑使用状态模式了。
<Design Pattern>State模式结构图
示例关系图
描述: 一年有12个月,有四个季度,每个月都有一属于一个季度,根据月份得到这个季度的天气信息.可以用State模式来实现.
关系图:
代码设计:
先创建接口IQuarter.cs:
再创建Quarter.cs:
再创建Summer.cs:
再创建 Autumn.cs:
再创建Winter.cs:
再创建MonthInfo.cs:
再调用它:
结果如图:
何时采用
3.从代码角度来说，如果一个类有多种状态，并且在类内部通过的条件语句判断的类状态来实现不同行为时候可以把这些行为单独封装为状态类。
4.从应用角度来说，如果一个对象有多种状态，如果希望把对象状态的转化以及由不同状态产生的行为交给具体的状态类去做，那么可以考虑状态模式。
效果及实现要点
1.在环境角色中拥有状态角色的实例。
2.在状态角色中拥有环境角色的实例用于在具体状态中修改环境角色的状态。
3.状态对象之间的依赖可以通过加载外部配置的转化规则表等方法来消除。
4.状态模式和策略模式的主要区别是，前者的行为实现方式是由条件决定的，并且应当能不在客户端干预的情况下自己迁移到合适的状态，而后者的行为实现方式是由客户端选择的，并且能随时替换。
总结
1.优点: 避免了为判断状态而产生的巨大的if或case语句。 将对象行为交给状态类维护后，对于上层程序而言，仅需要维护状态之间的转换规则。
2.缺点:会导致某些系统有过多的具体状态类。
3.过多的状态对象可能会增加系统负担，可以考虑把各种状态角色实现为无状态对象的享元，需要保存的额外状态由环境角色进行统一管理和处理。
]]>
概述
在软件系统中，有些对象有时候由于跨越网络或者其他的障碍，而不能够或者不想直接访问另一个对象，如果直接访问会给系统带来不必要的复杂性，这时候可以在客户程序和目标对象之间增加一层中间层，让代理对象来代替目标对象打点一切。这就是本文要说的Proxy模式。
意图
代理（Proxy）模式给某一个对象提供一个代理，并由代理对象控制对原对象的引用。
代理模式的英文叫做Proxy或Surrogate，中文都可译成"代理"。所谓代理，就是一个人或者一个机构代表另一个人或者另一个机构采取行动。在一些情况下，一个客户不想或者不能够直接引用一个对象，而代理对象可以在客户端和目标对象之间起到中介的作用。
<Design Pattern>Proxy模式结构图
图1 Proxy模式结构图
代理的种类
如果按照使用目的来划分，代理有以下几种：
远程（Remote）代理：为一个位于不同的地址空间的对象提供一个局域代表对象。这个不同的地址空间可以是在本机器中，也可是在另一台机器中。远程代理又叫做大使（Ambassador）。
虚拟（Virtual）代理：根据需要创建一个资源消耗较大的对象，使得此对象只在需要时才会被真正创建。
Copy-on-Write代理：虚拟代理的一种。把复制（克隆）拖延到只有在客户端需要时，才真正采取行动。
保护（Protect or Access）代理：控制对一个对象的访问，如果需要，可以给不同的用户提供不同级别的使用权限。
Cache代理：为某一个目标操作的结果提供临时的存储空间，以便多个客户端可以共享这些结果。
防火墙（Firewall）代理：保护目标，不让恶意用户接近。
同步化（Synchronization）代理：使几个用户能够同时使用一个对象而没有冲突。
智能引用（Smart Reference）代理：当一个对象被引用时，提供一些额外的操作，比如将对此对象调用的次数记录下来等。
在所有种类的代理模式中，虚拟（Virtual）代理、远程（Remote）代理、智能引用代理（Smart Reference Proxy）和保护（Protect or Access）代理是最为常见的代理模式。
西游记中的例子
尽管那时候八戒还不叫八戒，但为了方便，这里仍然这样称呼他。
高老庄的故事
却说那春融时节，悟空牵着白马，与唐僧赶路西行。忽一日天色将晚，远远地望见一村人，这就是高老庄，猪八戒的丈人高太公家。为了将高家三小姐解救出八戒的魔掌，悟空决定扮做高小姐，会一会这个妖怪：
"行者却弄神通，摇身一变，变得就如那女子一般，独自个坐在房里等那妖精。不多时，一阵风来，真个是走石飞砂……那阵狂风过处，只见半空里来了一个妖精，果然生得丑陋：黑脸短毛，长喙大耳，穿一领青不青、蓝不蓝的梭布直裰，系一条花布手巾……走进房，一把搂住，就要亲嘴……"
高家三小姐的神貌和本人
悟空的下手之处是将高家三小姐的神貌和她本人分割开来，这和"开一闭"原则有异曲同工之妙。这样一来，"高家三小姐本人"也就变成了"高家三小姐神貌"的具体实现，而"高家三小姐神貌"则变成了抽象角色，如下图所示。
悟空扮演并代替高家三小姐
悟空巧妙地实现了"高家三小姐神貌"，也就是说同样变成了"高家三小姐神貌"的子类。悟空可以扮演高家三小姐，并代替高家三小姐会见八戒，其静态结构图如下图所示。
悟空代替"高家三小姐本人"去会见猪八戒。显然这就是代理模式的应用。具体地讲，这是保护代理模式的应用。只有代理对象认为合适时，才会将客户端的请求传递给真实主题对象。
八戒分辨不出真假老婆
从《西游记》的描述可以看出，猪八戒根本份辨不出悟空扮演的"高家三小姐替身"和 "高家三小姐本人"。客户端分辨不出代理主题对象与真实主题对象，这是代理模式的一个
重要用意。
悟空代替高家三小姐会见八戒的对象图如下图所示。
示例用例图设计:
比如在大学时,每年学校都会举行元旦晚会,但学校是主办单位,而学生会是承办单位.这一模式正是我们的代理模式,用例图如下:
代码设计:
先创建接口IActivity.cs:
然后创建UnderTakeActivity.cs:
再创建SchoolActivity.cs:
最后调用:
结果如下:
效果及实现要点
Proxy模式根据种类不同，效果也不尽相同：
1．远程（Remote）代理：为一个位于不同的地址空间的对象提供一个局域代表对象。这个不同的地址空间可以是在本机器中，也可是在另一台机器中。远程代理又叫做大使（Ambassador）。好处是系统可以将网络的细节隐藏起来，使得客户端不必考虑网络的存在。客户完全可以认为被代理的对象是局域的而不是远程的，而代理对象承担了大部份的网络通讯工作。由于客户可能没有意识到会启动一个耗费时间的远程调用，因此客户没有必要的思想准备。
2．虚拟（Virtual）代理：根据需要创建一个资源消耗较大的对象，使得此对象只在需要时才会被真正创建。使用虚拟代理模式的好处就是代理对象可以在必要的时候才将被代理的对象加载；代理可以对加载的过程加以必要的优化。当一个模块的加载十分耗费资源的情况下，虚拟代理的好处就非常明显。
3．Copy-on-Write代理：虚拟代理的一种。把复制（克隆）拖延到只有在客户端需要时，才真正采取行动。
4．保护（Protect or Access）代理：控制对一个对象的访问，如果需要，可以给不同的用户提供不同级别的使用权限。保护代理的好处是它可以在运行时间对用户的有关权限进行检查，然后在核实后决定将调用传递给被代理的对象。
5．Cache代理：为某一个目标操作的结果提供临时的存储空间，以便多个客户端可以共享这些结果。
6．防火墙（Firewall）代理：保护目标，不让恶意用户接近。
7．同步化（Synchronization）代理：使几个用户能够同时使用一个对象而没有冲突。
8．智能引用（Smart Reference）代理：当一个对象被引用时，提供一些额外的操作，比如将对此对象调用的次数记录下来等。
9.代理模式应用非常广泛，如果你希望降低对象的使用复杂度、或是提升对象使用的友好度、或是提高对象使用的效率都可以考虑代理模式。
总结
1.在软件系统中，增加一个中间层是我们解决问题的常见手法，这方面Proxy模式给了我们很好的实现。
2,Proxy、Facade以及Adapter可能都是对对象的一层封装，侧重点不同。Proxy基于一致的接口进行封装，Facade针对封装子系统，转化为高层接口，而Adapter的封装是处于适配接口的目的。
作者: spring yang 发表于 2011-04-10 21:41 原文链接