设计模式之心得_设计模式心得体会

设计模式之心得由刀豆文库小编整理，希望给你工作、学习、生活带来方便，猜你可能喜欢“设计模式心得体会”。

刚学几天就有一些浅薄的心得了。

在学过的几种设计模式中（目前为止，本人只学过创建性模式），每一种设计模式都会有一种具体的应用场景，每一种场景描述的都是一种需求变化。设计模式就是用来解决这些变化的。

只要客户有新的需求，你的程序就要发生改变，不管你用什么方法，这个改变是避免不了的。关键是你如何是解决这种变化！设计模式就是寻求一种通用的较好的方法来解决这种变化而不是避免这种变化，并不是你应用了设计模式，你的系统就不会发生变化了。

面向对象的编程有三大机制，我个人认为，设计模式很好的利用了其中的“封装与多态”（当然并不是所有的设计模式都是这样的，也不是说继承就没用，继承在三大机制排第一呀，是基本的），比如工厂方法模式和生成器模式。“封装”的意义不仅仅在于封装代码的实现，更重要的是“封装”系统中变化的部分。设计模式回答了怎么样去“封装”这种变化。

在一个系统中，总会有一部分经常发生变化，相对的，也总有一个部分是改变频率较低的，我们可以在某种范围内将其理解为不改变的部分。设计模式要作的事情就是把“变化”的部分封装起来，实现将“变化”的部分与“不变化”的部隔离，这样，“变化”的部分在发生变化时，不会影响到“不改变”的部分。如果你也学过设计模式，那你可能跟我有同感。设计模式解决变化的途径可以概括为两步（纯属个人见解）：一是转移变化，二是转化变化。

首先是“转移变化”。

简单的说就是把A部分的变化转移到B部分，请B去变化，让A不发生变化。在程序中就是将变化从调用者转移到被调用者。比如，你有一个类scene，这个类用于显现一种风格的游戏场景，调用程序实例化这个类并使用它。如果有一天，需求改变了，当前风格的游戏场景颜色太冷了，我需要改变当前场景的颜色。这个时候你要决定，要让谁去发生变化？是让客户调用程序去改变scene类的颜色属性呢，还是让你的类scene发生变化？设计模式回答的是，请scene发生变化，调用者不发生变化。

为什么要这样回答，因为这个时候，你的系统可能已经交付用户了，如果让调用者发生变化，那整个系统都要发生变化。（这里讨论只是一个简单的应用，实际情况中往往没有这里简单。如果实际情况是这么简单的话，设计模式估计就没有用处了。）

然后是“转化变化”。

确定了要改动scene，那要怎么样去改scene呢？直接改吗？当然不行，如果是这样改，那还不如让调用者去设置scene的某个属性呢，反正都要重新部署。那要怎么改？“扩展”，把这种“改变”转化为“扩展”。你不是要另外一种

scene吗？那我重新为你设计一个sence并生成.dll交付你，然后让现有的程序去调用这个scene。当然，这时可能需要调用者稍微的发生一下变化，比如开始调用者是直接调用scene来呈现场景的，现在将其改为根据配置文件来决定要呈现那种scene。但是如果之前你已经考虑到这个问题了，那调用者是不需要发生任何变化的，因为调用者是根据配置来决定所呈现的场景，需求发生弯化，只需要改变配置文件（可能是一个ＸＭＬ），把调用者与新添的scene关联即可，这样一来，“改动”就变为“扩展”，其带来的好处也是显而易见的，这也就是所谓的“开闭”原则。

以上文字完全是本人理解，随着不断的学习，我想这么文章估计要被改好多次，这是一个学习的过程。理解错了、写错了都不要紧，关键是你怎么样去面对这种错误！是拒绝承认错误还是正视错误？这也是设计模式回答的问题。