我也只是一个普通的编程人员，这里只能谈一谈我在学习设计模式中的一些想法，不一定正确，欢迎大家谈论。我对设计模式的理解是分阶段的：
一、这是些什么乱七八糟的东西？那时候听到了设计模式的概念，到图书馆借了一本大概名字叫《设计模式初学者入门》之类的书。书里就把23个设计模式挨个讲了一遍，引用一下每个设计模式的定义，给个类图，配点代码……然后我硬着头皮读完之后，就一个感觉，“脱了裤子放屁”。一个功能，明明很简单、很直接的就能实现，为什么要添那么多的类，绕那么多的弯？记得当时也就懂了“单例模式”。
二、后来又找其他的书，这时候我读到了程杰的《大话设计模式》，其中用活字印刷的例子，讲解了曹操“对酒当歌，人生几何”的敢动，我仿佛一下子就开窍了。明白了设计模式，他最重要的目的就是为了应对“变化”。所以回过头来看，为什么之前能懂“单例模式”，就因为“单例模式”的目标很清晰，所以很好懂；反之，其他的设计模式，目标比较“复杂”，所以我懂不了。
三、但仅仅知道了设计模式的目标，还是没有解决我的疑惑。我记得当时我心里反反复复的一个问题，“有变化，改代码就行了呀。怎么改都是改，为什么就一定要想你（设计模式）说的那样改呢？”那时候我基本上是单兵作战，代码是自己一个人从头写到脚，哪里有问题我就可以改哪里，完全没有心理负担，呵呵。后来工作变动，开始了团队开发、维护别人的代码，以及使用第三方组建。我就自然而然的明白了，有些代码，是你只能用不能改的！典型的就是人家只给你一个已经编译的dll，你怎么改？坑爹呀！所以，那时候，我最先明白的就是Adapter模式，为什么要用Adapter？因为接口不一致，你不使用Adapter就用不了第三方的代码！
四、如果说上面这个阶段是“迫不得已”的使用设计模式，接下来就是我开始主动的思考和使用设计模式了。我有差不多一年的时间都是在维护公司遗留下来的老代码——足以让人崩溃的代码！每一次的bug fix，都不得不小心翼翼、如履薄冰，即使如此，仍然有很多次的改动，都是“按下了葫芦浮起了瓢”。让我充分的意识到什么叫“紧耦合”、“坏味道”，我们会有计划的做一些重构，在这些过程中，我都会主动的思考，能不能套用某种设计模式（但没有一次成功，老大不让，担不起责任呀——系统太老太大太脆弱，你懂的！呵呵）
五、真正的理解设计模式的核心思想。我认为我目前仍然没有达到这个程度，虽然可以随口说出一些耳熟能详的设计原则，“高内聚、低耦合”，“对扩展开放，对修改关闭”，“优先使用聚合”之类的。但理解仍然不深，很多时候觉得这也可那也可，拿不定主意。我觉得这是我代码写得太少的原因，需要在更多的实践中体会提高。
看完这些，你肯定知道，我对学习设计模式是持支持肯定态度的。那么，下面和同学们交流一下学习设计模式的方法吧。
一、实践。记得金旭亮老师曾经说过，“没有写过10万行代码，不要谈设计模式”，可能有点夸张，但道理是棒棒的。比如我，如果没有不得不深入到那些足够复杂足够混乱的代码，身心饱受摧残，不可能对设计模式的认识有质的提高。因为设计模式的一个重要应用场景，是应付那些复杂的业务逻辑、快速的需求变化，她的价值在这些地方，才能够清晰的体现出来。“坐而论道”是一种我们都期望的“懒人模式”，但估计很难有效——至少对于我这种资质平庸的人来说吧。
二、明白设计模式的目的。每一个设计模式，一定是要解决一定的问题的；并且解决这些问题是附带了条件的。比如，需求发生了变更，这是问题。如果没有其他约束，解决这个问题的办法很简单，就是改代码而已，加上一个if...else而已。但是，我们不能这些改！（理解这一点相当重要，切记切记。当然，你可能会问，为什么不能这么改呢？我们下面再说）我们不能修改类里面的代码，我们只能采取一些其他手段，比如继承、比如封装原有类，来实现新需求。这时候，设计模式就粉墨登场了。
三、上面所说，为什么不能直接改类里面的方法函数，比如直接加if...else？我们可以从两方面理解。一方面是“被动的”，比如我们是引用的一个编译了的dll，根本就改不了；或者是团队开发，别人不允许你改他们写好的类。另一方面是“主动的”，接前面“团队开发，别人不允许你改他们写好的类”，为什么他们不允许你改呢？是不是他们固执、偷懒，没有团队精神？你把官司打到大BOSS那里，可能会被一顿K。你需要仔细的体会，“类”的概念。类就是一种封装，封装就意味着拒绝修改——想一想为什么会有private关键字吧。好了，就不在这里展开了，不然又要写一本书了。你只需首先明白，设计模式，是一种“带着脚镣的舞蹈”；然后进一步思考，为什么需要这些脚镣即可。（当然，如果你够牛B，这些最终砸碎这些脚镣，不在此探讨范畴）
最后，我还是强调“实践”，如果想要更好的理解第二条、第三条，唯一有效的方法，可能就是实践了（前提是你已经或多或少的研究过设计模式了）。
随时随地看视频
