设计模式学习新体会

    从接触设计模式到不断的学习设计模式已经有差不错两年的时间了，在这之前发现学习了某个设计模式之后，貌似理解了，却是不知道怎么去使用这些所谓的精华经验。我一开始就是这个状态，不过，慢慢的我发现自己有了新的认识。

【初识设计模式】

    接触的第一个设计模式相关的书籍是《大话设计模式》当时总是以小菜自喻。觉得里面每个设计模式前边的故事情节非常的有吸引力。也非常的贴近生活。当然，书中的代码也是跟着实践了一遍，只是并不懂具体的设计模式内涵，对于类图也没有做深刻的剖析。

【项目中应用】

    在一次项目中，要求加入设计模式。通过场景分析，定下了几个设计模式。然后开始第二次学习讨论设计模式，具体要怎样去用。当时记得，找到了个共性的地方就是：先来个抽象类，然后让其子类去继承，实现方法。当时并没有太多的去在意类图。

【再学设计模式】

    有了前面的基础之后，再次学习设计模式

·看定义，知道这个设计模式是解决哪类问题的。

看某个设计模式的第一步就是要知道，这个设计模式是什么，即：看定义。定义里面的每一句话，每一个修饰语都要仔细的琢磨。下面给大家举个例子：

--命令模式：将一个请求封装为一个对象，从而使你可以用不同的请求对客户进行参数化；对请求排队或记录请求日志，以及支持可撤销的操作。

这个模式定义中主要阐述了两点，即以分号进行分割。注意里面的关键字：对请求封装、对象、请求排队（请求日志）、支持可撤销。

具体的含义，大家自己去悟就可以了。在这里我只是想说，要把你看到的每一句话，在不加入自己情感色彩的情况下，让定义中的每一句话，甚至是每一个词在代码在类图中得到印证。不要想当然的认为自己是理解了。俗话说的好，“是骡子是马，拉出来溜溜”。

·看类图，弄清类与类之间的关系，更清晰

还是以命令模式为例：

看到这个类图，首先应该引起注意的就是：类与类之间的关系。即：最上面的是接口还是抽象类、继承关系或实现关系影响的是哪几个类、类与类之间的聚合组合或依赖关系。

如上图所示：

在这个里面Command为所有命令声明了一个接口，调用命令对象的execute方法，同时这个接口也具有undo方法。

ConcreteCommand是具体的命令类，它定义了命令的接收者（Receiver），实现execute方法和undo方法。

Invoker类用来发出命令，即调用command对象的execute方法，将客户发过来的请求付诸行动。

在这里需要特别注意：客户发出请求，Invoker发出命令。具体的执行者是Receiver。

·走代码，对应类图和定义， 找自己不足

走代码的时候需要特别注意一下几个方面：

1、类与类之间的关联关系是如何体现的

还是看上图：Invorker和Command之间的关联关系体现通过一下代码：

class Invoker
{
   private Command command;
   Public void SetCommand(Command command)
   {
      this.command=command;
   }
  public void ExecuteCommand()
   {
      command.Execute();
   }
}

即：在Invoker类里面实例化一个Command类的对象，用于调用Command类的Execute方法，从而实现类与类之间的通信。

2、对象的声明（父类引用指向子类对象）

这个特点，贯穿整个设计模式。如此定义的好处是父类有的特征子类完全拥有。并且子类还具有多态性的特征。

·交流切磋，把自己知道讲出来，互相补充，共同进步。

最后一点是重中之重，通过跟小伙伴的交流切磋，才能知道自己真正的理解程度。从而查漏补缺，共同进步。还有一个很重要的原因就是，自己可能心里明白了，但是就是讲出来给大家听的效果非常不好，除了对知识掌握的不牢固，还有就是搞不清楚自己是不是真的弄明白了。鉴于以上两点不好的征兆，一定要注意学术交流的重要性和必要性。

【小结】

具体问题具体分析才是解题的正道。文章中是小编对自己这几次学习设计模式的感受和一些经验教训，希望对大家有所帮助。

转载于:https://www.cnblogs.com/fengkungui/p/6789580.html