亚洲自啪免费,欧美午夜精品一区,欧美精品日日鲁夜夜添

chatler — Wed, 08 Jun 2011 06:14:00 GMT

Introduction

Me and my wife had some interesting conversations on Object Oriented Design principles. After publishing the conversation on CodeProject, I got some good responses from the community and that really inspired me. So, I am happy to share our next conversation that took place on Object Oriented Design Patterns. Here it is.

What is a Design Pattern?

Shubho: I guess you already have some basic idea about Object Oriented Design principles. We had a nice talk on the OOD principles (SOLID principles), and I hope you didn't mind that I published our conversation in a CodeProject article. You can find it here: How I explained OOD to my wife.

Design Patterns are nothing but applications of those principles in some specific and common situations, and standardizing some of those. Let's try to understand what Design Patterns are by using some examples.

Farhana: Sure, I love examples.

Shubho: Let's talk about our car. It's an object, though a complex one, which consists of thousands of other objects such as the engine, wheels, steering, seats, body, and thousands of different parts and machinery.

Different parts of a car.

While building this car, the manufacturer gathered and assembled all the different smaller parts that are subsystems of the car. These different smaller parts are also some complex objects, and some other manufacturers had to build and assemble those too. But, while building the car, the car company doesn't really bother too much about how those objects were built and assembled (well, as long as they are sure about the quality of these smaller objects/equipments). Rather, the car manufacturer cares about how to assemble those different objects into different combinations and produce different models of cars.

Different models of cars, produced by assembling different parts and following different designs.

Farhana: The car manufacturer company must have some designs or blue prints for each different model of car which they follow, right?

Shubho: Definitely, and, these designs are well-thought designs, and they've put a good amount of time and effort to sketch those designs. Once the designs are finalized, producing a car is just a matter of following the designs.

Farhana: Hm.. it's good to have some good designs upfront and following those allows to produce different products in a quick amount of time, and each time the manufacturer has to build a product for a specific model, they don't have to develop a design from scratch or re-invent the wheel, they just follow the designs.

Different design plans for producing different models of products (cars).

Shubho: You got the point. Now, we are software manufacturers and we build different kinds of software programs with different components or functionality based upon the requirements. While building such different software systems, we often have to develop code for some situations that are common in many different software systems, right?

Farhana: Yes. And often, we face common design problems while developing different software applications.

Shubho: We try to develop our software applications in an Object Oriented manner and try to apply OOD principles for achieving code that is manageable, reusable, and expandable. Wouldn't it be nice whenever we see such design problems, we have a pool of some carefully made and well tested designs of objects for solving those?

Farhana: Yes, that would save us time and would also allow us to build better software systems and manage them later.

Shubho: Perfect. The good news is, you don't have to really develop that pool of object designs from scratch. People already have gone through similar design problems for years, and they already have identified some good design solutions which have been standardized already. We call these Design Patterns.

We must thank the Gang of Four (GoF) for identifying the 23 basic Design Patterns in their book Design Patterns: Elements of Reusable Object-Oriented Software. In case you are wondering who formed this famous gang, they are Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides. There are many Object Oriented Design Patterns, but these 23 patterns are generally considered the foundation for all other Design Patterns.

Farhana: Can I create a new pattern? Is that possible?

Shubho: Yes darling, why not? Design Patterns are not something invented or newly created by scientists. They are just discovered. That means, for each kind of common problem scenario, there must be some good design solutions there. If we are able to identify an object oriented design that could solve a new design related problem, that would be a new Design Pattern defined by us. Who knows? If we discover some a Design Pattern, someday people may call us Gang of Two.. Ha ha.

Fahana: :)

How will we learn Design Patterns?

Shubho: As I have always believed, examples are the greatest way of learning. In our learning approach, we won't discuss the theories first and implement later. I think this is a BAD approach. Design Patterns were not invented based on theories. Rather, the problem situations occurred first and based upon the requirement and context, some design solutions were evolved, and later some of them were standardized as patterns. So, for each design pattern we discuss, we will try to understand and analyze some real life example problems, and then we will try to formulate a design in a step by step process and end up with a design that will match with some patterns; Design Patterns were discovered in this same process. What do you think?

Farhana: I think this approach makes more sense to me. If I can end up with Design Patterns by analyzing problems and formulating solutions, I won't have to memorize design diagrams and definitions. Please proceed using your approach.

A basic design problem and its solution

Shubho: Let's consider the following scenario:

Our room has some electric equipments (lights, fans etc). The equipments are arranged in a way where they could be controlled by switches. At any time, you can replace or troubleshoot an electrical equipment without touching the other things. For example, you can replace a light with another without replacing or changing the switch. Also, you can replace a switch or troubleshoot it without touching or changing the corresponding light or fan; you can even connect the light with the fan's switch and connect the fan with the light's switch, without touching the switches.

Electrical equipments: A fan and a light.

Two different switches for fan and light, one is normal and the other is fancy.

Farhana: Yes, but that's natural, right?

Shubho: Yes, that's very natural, and that's how the arrangement should be. When different things are connected together, they should be connected in a way where change or replacement of one system doesn't affect another, or even if there is any effect, it stays minimal. This allows you to manage your system easily and at low cost. Just imagine if changing the light in your room requires you to change the switch also. Would you care to purchase and set up such a system in your house?

Farhana: Definitely no.

Shubho: Now, let's think how the lights or fans are connected with the switches so that changing one doesn't have any impact on the other. What do you think?

Farhana: The wire, of course!

Shubho: Perfect. It's the wire and the electrical arrangement that connect the lights/fans with the switches. We can generalize it as a bridge between the different systems that can get connected through it. The basic idea is, things shouldn't be directly connected with one another. Rather, they should be connected though some bridges or interfaces. That's what we call "loose coupling" in software world.

Farhana: I see. I got the idea.

Shubho: Now, let's try to understand some key issues in the light/fan and switch analogy, and try to understand how they are designed and connected.

Farhana: OK, let me try.

We have switches in our example. There may be some specific kinds of switches like normal switches, fancy ones, but, in general, they are switches. And, each switch can be turned on and off.

So, we will have a base Switch class as follows:

Collapse

public class Switch
{
  public void On()
  { 
    //Switch has an on button
  }
  public void Off()
  {
    //Switch has an off button
  }
}

And, as we may have some specific kinds of switches, for example a fancy switch, a normal switch etc., we will also have FancySwitch and NormalSwitch classes extending the Switch class:

Collapse

public class NormalSwitch : Switch
{
}

public class FancySwitch : Switch
{
}

These two specific switch classes may have their own specific features and behaviours, but for now, let's keep them simple.

Shubho: Cool. Now, what about fan and light?

Farhana: Let me try. I learned from the Open Closed principles from Object Oriented Design principles that we should try to do abstractions whenever possible, right?

Shubho: Right.

Farhana: Unlike switches, fan and light are two different things. For switches, we were able to use a baseSwitch class, but as fan and light are two different things, instead of defining a base class, an interface might be more appropriate. In general, they are all electrical equipments. So, we can define an interface, say,IElectricalEquipment, for abstracting fans and lights, right?

Shubho: Right.

Farhana: OK, each electrical equipment has some common functionality. They could all be turned on or off. So the interface may be as follows:

Collapse

public interface IElectricalEquipment
{
    void PowerOn(); //Each electrical equipment can be turned on
    void PowerOff(); //Each electrical equipment can be turned off
}

Shubho: Great. You are getting good at abstracting things. Now, we need a bridge. In real world, the wires are the bridges. But, in our object design, a switch knows how to turn on or off an electrical equipment, and the electrical equipment somehow needs to be connected with the switches, As we don't have any wire here, the only way to let the electrical equipment be connected with the switch is encapsulation.

Farhana: Yes, but switches don't know the fans or lights directly. A switch actually knows about an electrical equipment IElectricalEquipment that it can turn on or off. So, that means, an ISwitch should have anIElectricalEquipment instance, right?

Shubho: Right. Here, the encapsulated instance, which is an abstraction of fan or light (IElectricalEquipment) is the bridge. So, let's modify the Switch class to encapsulate an electrical equipment:

Collapse

public class Switch
{
  public IElectricalEquipment equipment
  {
    get;
    set;
  }
  public void On()
  {
    //Switch has an on button
  }
  public void Off()
  {
    //Switch has an off button
  }
}

Farhana: Understood. Let me try to define the actual electrical equipments, the fan and the light. As I see, these are electrical equipments in general, so these would simply implement the IElectricalEquipmentinterface.

Following is the Fan class:

Collapse

public class Fan : IElectricalEquipment
{
  public void PowerOn()
  {
    Console.WriteLine("Fan is on");
  }
  public void PowerOff()
  {
    Console.WriteLine("Fan is off");
  }
}

And, the Fan class would be as follows:

Collapse

public class Light : IElectricalEquipment
{
  public void PowerOn()
  {    
    Console.WriteLine("Light is on");
  }
  public void PowerOff()
  {
    Console.WriteLine("Light is off");
  }
}

Shubho: Great. Now, let's make switches work. The switches should have the ability inside them to turn on and turn off the electrical equipment (it is connected to) when the switch is turned on and off.

These are the key issues:

When the On button is pressed on the switch, the electrical equipment connected to it should be turned on.
When the Off button is pressed on the switch, the electrical equipment connected to it should be turned off.

Basically, following is what we want to achieve:

Collapse

static void Main(string[] args)
{
  //We have some electrical equipments, say Fan, Light etc.
  //So, lets create them first.

  IElectricalEquipment fan = new Fan();
  IElectricalEquipment light = new Light();

  //We also have some switches. Lets create them too.

  Switch fancySwitch = new FancySwitch();
  Switch normalSwitch = new NormalSwitch();

  //Lets connect the Fan to the fancy switch

  fancySwitch.equipment = fan;

  //As the switch now has an equipment (Fan),
  //so switching on or off should 
  //turn on or off the electrical equipment  

  fancySwitch.On(); //It should turn on the Fan. 

  //so, inside the On() method of Switch,  
  //we must turn on the electrical equipment.
    
  //It should turn off the Fan. So, inside the On() method of  
  fancySwitch.Off();
  //Switch, we must turn off the electrical equipment

  //Now, lets plug the light to the fancy switch

  fancySwitch.equipment = light;
  fancySwitch.On(); //It should turn on the Light now
  fancySwitch.Off(); //It should be turn off the Light now
}

Farhana: I got it. So, the On() method of the actual switches should internally call the TurnOn() method of the electrical equipment, and the Off() should call the TurnOff() method on the equipment. So, the Switchclass should be as follows:

Collapse

public class Switch
{
  public void On()
  {
    Console.WriteLine("Switch on the equipment");
    equipment.PowerOn();
  }
  public void Off()
  {
    Console.WriteLine("Switch off the equipment");
    equipment.PowerOff();
  }
}

Shubho: Great work. Now, this certainly allows you to plug a fan from one switch to another. But you see, the opposite should also work. That means, you can change the switch of a fan or light without touching the fan or light. For example, you can easily change the switch of the light from FancySwitch to NormalSwitch as follows:

Collapse

normalSwitch .equipment = light;
normalSwitch.On(); //It should turn on the Light now
normalSwitch.Off(); //It should be turn off the Light now

So, you see, you can vary both the switches and the electrical equipments without any effect on the other, and connecting an abstraction of the electrical equipment with a switch (via encapsulation) is letting you do that. This design looks elegant and good. The Gang of Four has named this a pattern: The Bridge Pattern.

Farhana: Cool. I think I've understood the idea. Basically, two systems shouldn't be connected or dependent on another directly. Rather, they should be connected or dependent via abstraction (as the Dependency Inversion principle and the Open-Closed principle say) so that they are loosely coupled, and thus we are able to change our implementation when required without much effect on the other part of the system.

Shubho: You got it perfect darling. Let's see how the Bridge Pattern is defined:

"Decouple an abstraction from its implementation so that the two can vary independently"

You will see that our design perfectly matches the definition. If you have a class designer (in Visual Studio, you can do that, and other modern IDEs should also support this feature), you will see that you have a class diagram similar to the following:

Class diagram of Bridge pattern.

Here, Abstraction is the base Switch class. RefinedAbstraction is the specific switch classes (FancySwitch, NormalSwitch etc.). Implementor is the IElectricalEquipment interface.ConcreteImplementorA and ConcreteImplementorB are the Fan and Light classes.

Farhana: Let me ask you a question, just curious. There are many other patterns as you said, why did you start with the Bridge pattern? Any important reason?

Shubho: A very good question. Yes, I started with the Bridge pattern and not any other pattern (unlike many others) because of a reason. I believe the Bridge pattern is the base of all Object Oriented Design Patterns. You see:

It teaches how to think abstract, which is the key concept of all Object Oriented Design Patterns.
It implements the basic OOD principles.
It is easy to understand.
If this pattern is understood correctly, learning other Design Patterns becomes easy.

Farhana: Do you think I have understood it correctly?

Shubho: I think you have understood it perfectly darling.

Farhana: So, what's next?

Shubho: By understanding the Bridge pattern, we have just started to understand the concepts of Design Patterns. In our next conversation, we would learn other Design Patterns, and I hope you won't get bored learning them.

Farhana: I won't. Believe me.

from:
http://www.codeproject.com/KB/architecture/LearningDesignPatterns1.aspx

chatler 2011-06-08 14:14 发表评论

chatler — Wed, 08 Jun 2011 05:45:00 GMT

摘要: Introduction My wife Farhana wants to resume her career as a software developer (she started her career as a software developer, but couldn't proceed much because of our first child's birth), and the... 阅读全文

chatler 2011-06-08 13:45 发表评论

�q�MM与设计模式的有趣见解

chatler — Sat, 05 Dec 2009 02:43:00 GMT

创徏型模�?

1�?span>FACTORY �?/span>�q?span>MM��不了请吃饭了，麦当劳的鸡翅和肯德基的鸡��都�?span>MM爱吃的东西，虽然口味有所不同�Q�但不管你带MM去麦当劳或肯德基�Q�只��向服务员说“来四个鸡��?span>”��p��了。麦当劳和肯德基��是生��鸡翅�?span>Factory

工厂模式�Q�客��L��和工厂类分开。消费者�Q何时候需要某�U��品，只需向工厂请求即可。消费者无��M��改就可以接纳��C�品。缺�Ҏ��当��品修�Ҏ��Q�工厂类也要做相应的修改。如�Q�如何创建及如何向客��L��提供�?

2�?span>BUILDER —MM最爱听的就�?span>“我爱�?span>”�q�句话了�Q�见��C��同地方的MM,要能够用她们的方�a�跟她说这句话哦，我有一个多�U�语�a��译机，上面每种语言都有一个按键，见到MM我只要按对应的键�Q�它��p��够用相应的语�a�说出“我爱�?span>”�q�句话了�Q�国外的MM也可以轻松搞掂，�q�就是我�?span>“我爱�?span>”builder。（�q�一定比��军在伊拉克用的��译机好卖）

建造模�?/span>�Q�将产品的内部表象和产品的生成过�E�分割开来，从而��一个徏造过�E�生成具有不同的内部表象的��品对象。徏造模式��得��品内部表象可以独立的变化�Q�客户不必知道��品内部组成的�l�节。徏造模式可以强制实行一�U�分步骤�q�行的徏造过�E��?

3�?span>FACTORY METHOD �?/span>�?span>MM去麦当劳吃汉堡，不同�?span>MM有不同的口味�Q�要每个都记住是一件烦人的事情�Q�我一般采�?span>Factory Method模式�Q�带着MM到服务员那儿�Q�说“要一个汉�?span>”�Q�具体要什么样的汉堡呢�Q�让MM直接跟服务员说就行了�?

工厂�Ҏ��模式�Q�核心工厂类不再负责所有��品的创徏�Q�而是��具体创建的工作交给子类��d��Q�成��Z��个抽象工厂角�Ԍ��仅负责给出具体工厂类必须实现的接口，而不接触哪一个��品类应当被实例化�q�种�l�节�?

4�?span>PROTOTYPE �?/span>�?span>MM�?span>QQ聊天�Q�一定要说些深情的话语了�Q�我搜集了好多肉�ȝ��情话�Q�需要时只要copy出来攑ֈ�QQ里面��p��了，�q�就是我的情�?span>prototype了。（100块钱一份，你要不要�Q?

原始模型模式�Q�通过�l�出一个原型对象来指明所要创建的对象的类型，然后用复制这个原型对象的�Ҏ��创徏出更多同�c�d��的对象。原始模型模式允许动态的增加或减��品类�Q��品类不需要非得有��M��事先��定的等�U�结构，原始模型模式适用于�Q何的�{��l�构。缺�Ҏ��每一个类都必��配备一个克隆方法�?

5�?span>SINGLETON �?/span>俺有6个漂亮的老婆�Q�她们的老公都是我，我就是我们家里的老公Sigleton�Q�她们只要说�?span>“老公”�Q�都是指的同一个�h�Q�那��是�?span>(刚才做了个梦啦，哪有�q�么好的�?span>)

单例模式�Q�单例模式确保某一个类只有一个实例，而且自行实例化�ƈ向整个系�l�提供这个实例单例模式。单例模式只应在有真正的“单一实例”的需求时才可使用�?

�l�构型模�?

6�?span>ADAPTER �?/span>在朋友聚会上��到了一个美�?span>Sarah�Q�从香港来的�Q�可我不会说�_�语�Q�她不会说普通话�Q�只好求助于我的朋友kent了，他作为我�?span>Sarah之间�?span>Adapter�Q�让我和Sarah可以�怺�交谈�?span>(也不知道他会不会耍我)

适配器模�?/span>�Q�把一个类的接口变换成客户端所期待的另一�U�接口，从而��原本因接口原因不匚w��而无法一起工作的两个�c�能够一起工作。适配�c�d��以根据参数返�q�一个合适的实例�l�客��L��?

7�?span>BRIDGE �?/span>早上��到MM�Q�要说早上好�Q�晚上碰�?span>MM�Q�要说晚上好�Q�碰�?span>MM�I�了件新衣服�Q�要说你的衣服好漂亮哦，��到MM新做的发型，要说你的头发好漂亮哦。不要问�?span>“早上��到MM新做了个发型怎么�?span>”�q�种问题�Q�自��q��BRIDGE�l�合一下不��p��?

桥梁模式�Q�将抽象化与实现化脱耦，使得二者可以独立的变化�Q�也��是说将他们之间的强兌��变成弱关联，也就是指在一个��Y件系�l�的抽象化和实现化之间��用组�?span>/聚合关系而不是��承关�p�，从而��两者可以独立的变化�?

8�?span>COMPOSITE —Mary今天�q�生日�?span>“我过生日�Q�你要送我一件礼物�?span>”“嗯，好吧�Q�去商店�Q�你自己挑�?span>”“�q��gT恤挺漂亮�Q�买�Q�这条裙子好看，乎ͼ��q�个包也不错�Q�买�?span>”“喂，��C��三�g了呀�Q�我只答应送一件礼物的哦�?span>”“什么呀�Q?span>T恤加裙子加包包，正好配成一套呀�Q�小姐，�ȝ��你包��h��?span>”“……”�Q?span>MM都会�?span>Composite模式了，你会了没有？

合成模式�Q�合成模式将对象�l�织到树�l�构中，可以用来描述整体与部分的关系。合成模式就是一个处理对象的树结构的模式。合成模式把部分与整体的关系用树�l�构表示出来。合成模式��得客��L��把一个个单独的成分对象和�׃��们复合而成的合成对象同�{�看待�?

9�?span>DECORATOR —Mary�q�完轮到Sarly�q�生日，�q�是不要叫她自己挑了�Q�不然这个月伙食费肯定玩完，拿出我去�q�在华山��上照的照片�Q�在背面写上“最好的的礼物，��是�׃��?span>Fita”�Q�再到街上礼品店��C��个像框（卖礼品的MM也很漂亮哦）�Q�再��N��壁搞��术设计�?span>Mike设计了一个漂亮的盒子装�v�?span>……�Q�我们都�?span>Decorator�Q�最�l�都在修饰我�q�个人呀�Q�怎么��P��看懂了吗�Q?

装饰模式�Q�装饰模式以对客��L��透明的方式扩展对象的功能�Q�是�l�承关系的一个替代方案，提供比��承更多的灉|��性。动态给一个对象增加功能，�q�些功能可以再动态的撤消。增加由一些基本功能的排列�l�合而��生的非常大量的功能�?

10�?span>FAÇADE �?/span>我有一个专业的Nikon相机�Q�我��喜�Ƣ自己手动调光圈、快门，�q�样照出来的照片才专业，�?span>MM可不懂这些，教了半天也不会。幸好相机有Facade设计模式�Q�把相机调整到自动档�Q�只要对准目标按快门��p��了，一切由相机自动调整�Q�这�?span>MM也可以用�q�个相机�l�我拍张照片了�?

门面模式�Q�外部与一个子�pȝ��的通信必须通过一个统一的门面对象进行。门面模式提供一个高层次的接口，使得子系�l�更易于使用。每一个子�pȝ��只有一个门面类�Q�而且此门面类只有一个实例，也就是说它是一个单例模式。但整个�pȝ��可以有多个门面类�?

11�?span>FLYWEIGHT �?/span>每天�?span>MM发短信，手指都篏��M��Q�最�q�买了个新手机，可以把一些常用的句子存在手机里，要用的时候，直接拿出来，在前面加�?span>MM的名字就可以发送了�Q�再不用一个字一个字敲了。共享的句子��是Flyweight�Q?span>MM的名字就是提取出来的外部特征�Q�根据上下文情况使用�?

享元模式�Q?span>FLYWEIGHT在拳��L��赛中指最轻量�U�。��n元模式以�׃�n的方式高效的支持大量的细�_�度对象。��n元模式能做到�׃�n的关键是区分内蕴状态和外蕴状态。内蕴状态存储在享元内部�Q�不会随环境的改变而有所不同。外蕴状态是随环境的改变而改变的。外蕴状态不能媄响内蕴状态，它们是相互独立的。将可以�׃�n的状态和不可以共享的状态从常规�c�M��区分开来，��不可以�׃�n的状态从�c�里剔除出去。客��L��不可以直接创��׃�n的对象，而应当��用一个工厂对象负责创��׃�n的对象。��n元模式大�q�度的降低内存中对象的数量�?

12�?span>PROXY �?/span>�?span>MM在网上聊天，一开头��L��“hi,你好”,“你从哪儿来呀�Q?span>”“你多大了�Q?span>”“�w�高多少呀�Q?span>”�q�些话，真烦人，写个�E�序做�ؓ我的Proxy吧，凡是接收到这些话都设�|�好了自动的回答�Q�接收到其他的话时再通知我回�{�，怎么��P��酷吧�?

代理模式�Q�代理模式给某一个对象提供一个代理对象，�q�由代理对象控制�Ҏ��对象的引用。代理就是一个�h或一个机构代表另一个�h或者一个机构采取行动。某些情况下�Q�客户不��x��者不能够直接引用一个对象，代理对象可以在客户和目标对象直接起到中介的作用。客��L��分��L不出代理主题对象与真实主题对象。代理模式可以�ƈ不知道真正的被代理对象，而仅仅持有一个被代理对象的接口，�q�时候代理对象不能够创徏被代理对象，被代理对象必��L��pȝ��的其他角色代为创建�ƈ传入�?

行�ؓ模式

13�?span>CHAIN OF RESPONSIBLEITY �?/span>晚上��M��p��课，��Z��好开溜坐��C��最后一排，哇，前面坐了好几个漂亮的MM哎，扑ּ��U�条�Q�写�?span>“Hi,可以做我的女朋友吗？如果不愿意请向前�?span>”�Q�纸条就一个接一个的传上��M��Q�糟�p�，传到�W�一排的MM把纸条传�l�老师了，听说是个老处奛_��Q�快�?span>!

责�Q链模�?/span>�Q�在责�Q链模式中�Q�很多对象由每一个对象对其下家的引用而接��h��形成一条链。请求在�q�个链上传递，直到链上的某一个对象决定处理此��h��。客户�ƈ不知道链上的哪一个对象最�l�处理这个请求，�pȝ��可以在不影响客户端的情况下动态的重新�l�织铑֒�分配责�Q。处理者有两个选择�Q�承担责��L��者把责�Q推给下家。一个请求可以最�l�不被�Q何接收端对象所接受�?

14�?span>COMMAND �?/span>俺有一�?span>MM安��得特别严，没法见面�Q�只好借助于她弟弟在我们俩之间传送信息，她对我有什么指�C�，��写一张纸条让她弟弟带�l�我。这不，她弟弟又传送过来一�?span>COMMAND�Q��ؓ了感谢他�Q�我请他吃了��杂酱面�Q�哪知道他说�Q?span>“我同时给我姐姐三个男朋友�?span>COMMAND�Q�就��C��最��气�Q�才��h��吃面�?span>”�Q?/span>

命��o模式�Q�命令模式把一个请求或者操作封装到一个对象中。命令模式把发出命��o的责��d��执行命��o的责��d��割开�Q�委�z��不同的对象。命令模式允许请求的一方和发送的一方独立开来，使得��h��的一方不必知道接收请求的一方的接口�Q�更不必知道��h��是怎么被接�Ӟ��以及操作是否执行�Q�何时被执行以及是怎么被执行的。系�l�支持命令的撤消�?

15�?span>INTERPRETER �?/span>俺有一个《��MM真经》，上面有各�U��MM的攻略，比如说去吃西��的步骤、去看电��q��Ҏ��{�等�Q�跟MM�U�会�Ӟ��只要做一�?span>Interpreter�Q�照着上面的脚本执行就可以了�?

解释器模�?/span>�Q�给定一个语�a�后，解释器模式可以定义出其文法的一�U�表�C�，�q�同时提供一个解释器。客��L��可以使用�q�个解释器来解释�q�个语言中的句子。解释器模式��描�q�怎样在有了一个简单的文法后，使用模式设计解释�q�些语句。在解释器模式里面提到的语言是指��M��解释器对象能够解释的��M��l�合。在解释器模式中需要定义一个代表文法的命��o�cȝ��{��l�构�Q�也��是一�p�d��的组合规则。每一个命令对象都有一个解释方法，代表对命令对象的解释。命令对象的�{��l�构中的对象的�Q何排列组合都是一个语�a��?

16�?span>ITERATOR �?/span>我爱上了Mary�Q�不��一切的向她求婚�?
   Mary�Q?span>“惌��我跟你结婚，得答应我的条�?span>”
   我：“什么条件我都答应，你说�?span>”
   Mary�Q?span>“我看上了那个一克拉的钻�?span>”
   我：“我买�Q�我乎ͼ��q�有吗？”
   Mary�Q?span>“我看上了湖边的那栋别�?span>”
   我：“我买�Q�我乎ͼ��q�有吗？”
   Mary�Q?span>“你的��弟弟必��要�?chmetcnv unitname="cm" sourcevalue="50" hasspace="False" negative="False" numbertype="1" tcsc="0" w:st="on">50cm�?span>”
   我脑袋嗡的一壎ͼ�坐在椅子上，一咬牙�Q?span>“我剪�Q�我剪，�q�有吗？”
   ……

�q�代子模�?/span>�Q��P代子模式可以��序讉K��一个聚集中的元素而不必暴露聚集的内部表象。多个对象聚在一起�Ş成的��M��U�C��集，聚集对象是能够包容一�l�对象的容器对象。�P代子模式��P代逻辑��装��C��个独立的子对象中�Q�从而与聚集本��n隔开。�P代子模式��化了聚集的界面。每一个聚集对象都可以有一个或一个以上的�q�代子对象，每一个�P代子的�P代状态可以是彼此独立的。�P代算法可以独立于聚集角色变化�?

17�?span>MEDIATOR �?/span>四个MM打麻��，�怺�之间谁应该给谁多��钱��不清楚了，�q怺�当时我在旁边�Q�按照各自的�{�码数算钱，赚了��q��从我�q�里拿，赔了��q��也付�l�我�Q�一切就OK啦，俺得��C��四个MM的电话�?

调停者模�?/span>�Q�调停者模式包装了一�p�d��对象�怺�作用的方式，使得�q�些对象不必�怺�明显作用。从而��他们可以松散偶合。当某些对象之间的作用发生改变时�Q�不会立卛_��响其他的一些对象之间的作用。保证这些作用可以彼此独立的变化。调停者模式将多对多的�怺�作用转化��Z��对多的相互作用。调停者模式将对象的行为和协作抽象化，把对象在��尺度的行�ؓ上与其他对象的相互作用分开处理�?

18�?span>MEMENTO �?/span>同时跟几�?span>MM聊天�Ӟ��一定要记清楚刚才跟MM说了些什么话�Q�不�?span>MM发现了会不高兴的哦，�q怺�我有个备忘录�Q�刚才与哪个MM说了什么话我都拯��一份放到备忘录里面保存�Q�这样可以随时察看以前的记录啦�?

备忘录模�?/span>�Q�备忘录对象是一个用来存储另外一个对象内部状态的快照的对象。备忘录模式的用意是在不破坏��装的条件下�Q�将一个对象的状态捉住，�q�外部化�Q�存储�v来，从而可以在��来合适的时候把�q�个对象�q�原到存储�v来的状态�?

19�?span>OBSERVER �?/span>想知道咱们公司最�?span>MM情报吗？加入公司�?span>MM情报邮�g�l�就行了�Q?span>tom负责搜集情报�Q�他发现的新情报不用一个一个通知我们�Q�直接发布给邮�g�l�，我们作�ؓ订阅者（观察者）��可以及时收到情报啦

观察者模�?/span>�Q�观察者模式定义了一�U�一队多的依赖关�p�，让多个观察者对象同时监听某一个主题对象。这个主题对象在状态上发生变化�Ӟ��会通知所有观察者对象，使他们能够自动更新自己�?

20�?span>STATE �?/span>�?span>MM交往�Ӟ��一定要注意她的状态哦�Q�在不同的状态时她的行�ؓ会有不同�Q�比如你�U�她今天晚上�ȝ��电媄�Q�对你没兴趣�?span>MM��׃��?span>“有事情啦”�Q�对你不讨厌但还没喜�Ƣ上�?span>MM��׃��?span>“好啊�Q�不�q�可以带上我同事么？”�Q�已�l�喜�Ƣ上你的MM��׃��?span>“几点钟？看完电媄再去泡吧怎么��P��”�Q�当然你看电��p��E�中表现良好的话�Q�也可以�?span>MM的状态从不讨厌不喜欢变成喜欢哦�?

状态模�?/span>�Q�状态模式允�怸�个对象在其内部状态改变的时候改变行为。这个对象看上去象是改变了它的类一栗��状态模式把所研究的对象的行�ؓ包装在不同的状态对象里�Q�每一个状态对象都属于一个抽象状态类的一个子�c�R��状态模式的意图是让一个对象在其内部状态改变的时候，其行��Z��随之改变。状态模式需要对每一个系�l�可能取得的状态创立一个状态类的子�c�R��当�pȝ��的状态变化时�Q�系�l�便改变所选的子类�?

21�?span>STRATEGY �?/span>跟不同类型的MM�U�会�Q�要用不同的�{�略�Q�有的请电媄比较好，有的则去吃小吃效果不错，有的��L�v�Ҏ��漫最合适，单目的都是�ؓ了得�?span>MM的芳心，我的�q?span>MM锦囊中有好多Strategy哦�?

�{�略模式�Q�策略模式针对一�l�算法，��每一个算法封装到��h��共同接口的独立的�c�M��Q�从而��得它们可以相互替换。策略模式��得算法可以在不媄响到客户端的情况下发生变化。策略模式把行�ؓ和环境分开。环境类负责�l�持和查询行为类�Q�各�U�算法在具体的策略类中提供。由于算法和环境独立开来，��法的增减，修改都不会媄响到环境和客��L��?

22�?span>TEMPLATE METHOD —�?/span>看过《如何说服女生上床》这部经典文章吗�Q�女生从认识��C��床的不变的步骤分为��y遇、打破僵局、展开�q�求、接吅R��前戏、动手、爱抚、进��d��大步�?span>(Template method)�Q�但每个步骤针对不同的情况，都有不一��L��做法�Q�这��p��看你随机应变�?span>(具体实现)�Q?

模板�Ҏ��模式�Q�模板方法模式准备一个抽象类�Q�将部分逻辑以具体方法以及具体构造子的�Ş式实玎ͼ�然后声明一些抽象方法来�q��子类实现剩余的逻辑。不同的子类可以以不同的方式实现�q�些抽象�Ҏ��Q�从而对剩余的逻辑有不同的实现。先制定一个顶�U�逻辑框架�Q�而将逻辑的细节留�l�具体的子类��d��现�?

23�?span>VISITOR �?/span>情�h节到了，要给每个MM送一束鲜花和一张卡片，可是每个MM送的花都要针对她个�h的特点，每张卡片也要�Ҏ��个�h的特�Ҏ��挑，我一个�h哪搞得清楚，�q�是找花店老板和礼品店老板做一�?span>Visitor�Q�让花店老板�Ҏ��MM的特炚w��一束花�Q�让�C�品店老板也根据每个�h特点选一张卡�Q�这样就��L��多了�Q?

讉K��者模�?/span>�Q�访问者模式的目的是封装一些施加于某种数据�l�构元素之上的操作。一旦这些操作需要修改的话，接受�q�个操作的数据结构可以保持不变。访问者模式适用于数据结构相�Ҏ��定的�pȝ��Q�它把数据结构和作用于结构上的操作之间的耦合解脱开�Q��得操作集合可以相对自��q��演化。访问者模式��得增加新的操作变的很�Ҏ��Q�就是增加一个新的访问者类。访问者模式将有关的行为集中到一个访问者对象中�Q�而不是分散到一个个的节点类中。当使用讉K��者模式时�Q�要��尽可能多的对象��览逻辑攑֜�讉K��者类中，而不是放到它的子�c�M��。访问者模式可以跨�q�几个类的等�U�结构访问属于不同的�{��l�构的成员类�?/span>

chatler 2009-12-05 10:43 发表评论