《设计模式》学习心得 ——设计模式是怎样解决设计问题的，在实际编程中是如何使用的？

1、设计模式是怎样解决设计问题的

（1）设计模式：—Abstract Factory，Factory Method，Prototype。通过显式地指定一个类来创建对象 在创建对象时指定类名称使你受特定实现的约束而不是特定接口的约束。这会使未来的变化更复杂。要避免这种情况，应该间接地创建对象。

（2）设计模式：—Chain of Responsibility，Command。对特殊操作的依赖 当你为请求指定一个特殊的操作时，完成该请求的方式就固定下来了。为避免把请求代码写死，你将可以在编译时刻或运行时刻很方便地改变响应请求的方法。

（3）设计模式：—Abstract Factory，Bridge。对硬件和软件平台的依赖 外部的操作系统接口和应用编程接口（API）在不同的软硬件平台上是不同的。依赖于特定平台的软件将很难移植到其他平台上，甚至都很难跟上本地平台的更新。所以设计系统时限制其平台相关性就很重要了。

（4）设计模式：—Abstract Factory，Bridge，Memento，Proxy。对对象表示或实现的依赖 知道对象怎样表示、保存、定位或实现的客户在对象发生变化时可能也需要变化。对客户隐藏这些信息能阻止连锁变化。

（5）设计模式：—Builder，Iterator，Strategy，Template Method，Visitor。算法依赖 算法在开发和复用时常常被扩展、优化和替换。依赖于某个特定算法的对象在算法发生变化时不得不变化。因此有可能发生变化的算法应该被孤立起来。

（6）设计模式：—Abstract Factory，Command，Facade，Mediator，Observer，Chain of Responsibility。紧耦合 紧耦合的类很难独立地被复用，因为它们是互相依赖的。紧耦合产生单块的系统，要改变或删掉一个类，你必须理解和改变其他许多类。这样的系统是一个很难学习、移植和维护的密集体。 松散耦合提供了一个类本身被复用的可能性，并且系统更易于学习、移植、修改和扩展。设计模式使用抽象耦合和分层技术来提高系统的松散耦合性。

（7）设计模式：—Bridge，Chain of Responsibility，Composite，Decorator，Observer，Strategy。通过生成子类来扩充功能 通常很难通过定义子类来定制对象。每一个新类都有固定的视线开销（初始化、终止处理等）。定义子类还需要对父类有深入的了解。如，重定义一个操作可能需要重定义其他操作。一个被重定义的操作可能需要调用继承下来的操作。并且子类方法会导致类爆炸，因为即使对于一个简单的扩充，你也不得不引入许多新的子类。 一般的对象组合技术和具体的委托技术，是继承之外组合对象行为的另一种灵活方法。新的功能可以通过以新的方式组合已有对象，而不是通过定义已存在类的子类的方式加到应用中去。另一方面，过多使用对象组合会使设计难于理解。许多设计模式产生的设计中，你可以定义一个子类，且将它的实例和已存在实例进行组合来引入定制的功能。

（8） 设计模式：—Adapter，Decorator，Visitor。不能方便地对类进行修改 有时你不得不改变一个难以修改的类。也许你需要源代码而又没有（对于商业类型库就有这种情况），或者可能对类的任何改变会要求修改许多已存在的其他子类。设计模式提供在这些情况下对类进行修改的方法。

2、如何在实际编程中使用设计模式

如何在实际编程中使用设计模式实际上就是如何运用设计模式让自己的代码具有可扩展性。在看一些开源框架的时候，发现框架里面到处都是设计模式，还有很多变种，当我们没有把设计模式融汇贯通的时候，我们总会觉得这些大牛确实厉害，但是老是把一些很简单的功能写得很绕。如果有这种想法，要么大牛水平不行，要么我们自己就根本没有理解大牛意图。恰到好处的运用设计模式，代码有了可读性以后，我们就可以进一步升华我们的代码：恰到好处的运用设计模式。为什么要强调恰到好处呢？我见过很多人过度设计的代码，包括我自己，时间花了不少，最后发现这个设计从来没有用上，反而让代码变得匪夷所思。如何判断自己有没有过度设计呢，这是一个非常复杂的自我博弈过程，需要丰富的经验，我自己一个模糊的判断方法：比较犹豫要不要在此处使用某个设计模式的时候，那就选择不要。因为过度设计很可怕，比不设计还糟糕。运用设计模式，首先我们需要了解什么是设计模式，有哪些常用的设计模式；然后再去看开源框架、造轮子，去真正理解大牛们是如何运用设计模式的，以及为什么要在这里运用这个设计模式；最后将设计模式运用到我们自己的代码里。开始可能会有点生硬，慢慢会变得越来越自然，此时，已经将设计模式融会贯通了，因为我们学会了将设计模式在真实场景下如何做少量调整，而早期可能只会死搬硬套。看开源框架、造轮子看开源框架，刚开始比较痛苦，发现好多地方看不懂。早期看 Spring 的源码的时候，就有很多地方不太理解，比较有挫败感，不过，这都是很正常的，因为开源项目往往比较复杂，而且可能还有一些历史包袱的存在。看懂多少算多少，不必强求，下次在使用这个功能的时候，反复看看，每次看都会有更进一步的理解。到最后发现几乎能全部看懂。看开源项目的速度变快，因为每当我们看到某处使用到了某个设计模式的时候，自然而然推测出这个功能是怎么实现的了，以及这样实现会带来什么好处。看懂源代码，甚至发现框架的设计还不是最好的。这个时候，可以尝试去造轮子，造轮子的过程是吸收别人优秀的设计，去掉别人不足的地方，最后最好再加上自己的创新。