设计模式心得体会
----------计算机学院软件工程14-1BF 黄东东
通过一个学期的设计模式的学习，我想在这里谈一谈我在学习设计模式中的一些想法，不一定正确，首先我对设计模式的理解是分阶段的：
一、这是些什么乱七八糟的东西？那时候刚听到了老师讲设计模式的概念的感觉，听不懂我就跑图书馆借了一本名字叫《设计模式初学者入门》之类的书。书里就把各种设计模式挨个讲了遍，引用一下每个设计模式的定义，给个类图，配点代码„„我硬着头皮读完之后，就一个感觉，为什么一个很简单、很直接就能实现的功能，为什么要添那么多的类，绕那么多的弯？觉并没有什么了不起的地方。所以前几次课难免会比较懒散不以为意，这时候老师开始讲工厂模式和建造模式，工厂模式是我们最常用的实例化对象模式了，是用工厂方法代替new操作的一模式，我们经常要根据类Cla生成实例对象，如A a=new A() 工厂模式也是用来创建实例对象的，所以以后new时就要多个心眼，是否可以考虑使用工厂模式，虽然这样做，可能多做一些 工作，但会给你系统带来更大的可扩展性和尽量少的修改量。建造模就是将一个复杂对象的构建与它的表示分离，使得同样的构建过程可以创建不同的表示。我第一次感觉这种方法很实用，老师也称之为“套路“，感觉上很有用，我产生了浓厚的兴趣。
二、我开始看其他的书，这时候我读到了程杰的《大话设计模式》，其中用活字印刷的例子，讲解了曹操“对酒当歌，人生几何”的敢动，我仿佛一下子就开窍了。明白了设计模式，他最重要的目的就是为了应对“变化”。一般的设计模式，目标比较“复杂”，并不是我所想的那么单刀直入，我们想的往往过于简单了，最后什么都做不出来，我们需要这样的套路，我们需要设计模式，我开始认真学。
三、但仅仅知道了设计模式的目标，还是没有解决我的疑惑。我记得当时我心里反反复复的一个问题，“有变化，改代码就行了呀。怎么改都是改，为什么就一定要像设计模式说的那样改呢？”那时候我基本上是单兵作战，代码是自己一个人从头写到脚，哪里有问题我就可以改哪里，完全没有心理负担。后来一想以后的工作会有变动，会开始团队开发、会维护别人的代码等等。我就自然而然的明白了，有些代码，是你只能用不能改的！典型的就是人家只给你一个已经编译的dll，你怎么改？所以，我上课开始发现老师讲的大概是什么了，我觉得十分的重要，那时候，我最先明白的就是桥接模式，在软件系统中，某些类型由于自身的逻辑，它具有两个或多个维度的变化，这就要使用Bridge模式应对这种“多维度的变化”，也就是桥接模式，它利用面向对象的技术来使得该类型能够轻松的沿着多个方向进行变化，而又不引入额外的复杂度，所谓抽象和实现沿着各自维度的变化，即“子类化”它们，得到各个子类之后，便可以任意它们。以达到你的目的，Bridge模式有时候类似于多继承方案，但是多继承方案往往违背了类的单一职责原则（即一个类只有一个变化的原因），复用性比较差。Bridge模式是比多继承方案更好的解决方法。，另一个就是Bridge模式的应用一般在“两个非常强的变化维度”，有时候即使有两个变化的维度，但是某个方向的变化维度并不剧烈——换言之两个变化不会导致纵横交错的结果，并不一定要使用Bridge模式。
四、如果说上面这个阶段是被动学习设计模式，照葫芦画瓢，接下来就是我开始主动的思考和使用设计模式了，在一些编码过程中，我都会主动的思考，能不能套用某种设计模式，但是对于学生来说，时间太少了，又要上课又要各种考试各种会议各种复习考试，所以一一直挤时间，谈不上真正的理解设计模式的核心思想。我认为我目前仍然没有达到这个程度，虽然可以随口说出一些耳熟能详的设计模式特点，但理解仍然不深，很多时候觉得这也可那也可，拿不定主意。我觉得这是我代码写得太少的原因，需要在更多的实践中体会提高。
看完这些，我对学习设计模式是持支持肯定态度的。那么，下面和大家交流一下学习设计模式的方法吧。
一、实践。记得金旭亮老师曾经说过，“没有写过10万行代码，不要谈设计模式”，可能有点夸张，但道理是棒棒的。如果没有不得不深入到那些足够复杂足够混乱的代码，身心饱受摧残，不可能对设计模式的认识有质的提高。因为设计模式的一个重要应用场景，是应付那些复杂的业务逻辑、快速的需求变化，它的价值在这些地方，才能够清晰的体现出来。“坐而论道”是一种我们都期望的“懒人模式”，但估计很难有效——至少对于我这种资质平庸的人来说吧。
二、明白设计模式的目的。每一个设计模式，一定是要解决一定的问题的；并且解决这些问题是附带了条件的。比如，需求发生了变更，这是问题。如果没有其他约束，解决这个问题的办法很简单，就是改代码而已，加上一个if...else而已。但是，我们不能这样改！我们不能修改类里面的代码，我们只能采取一些其他手段，比如继承、比如封装原有类，来实现新需求。这时候，设计模式就粉墨登场了。
三、上面所说，为什么不能直接改类里面的方法函数，比如直接加if...else？我们可以从两方面理解。一方面是“被动的”，比如我们是引用的一个编译了的dll，根本就改不了；或者是团队开发，别人不允许你改他们写好的类。另一方面是“主动的”，接前面“团队开发，别人不允许你改他们写好的类”，为什么他们不允许你改呢？是不是他们固执、偷懒，没有团队精神？你把官司打到大BOSS那里，可能会被一顿K。你需要仔细的体会，“类”的概念。类就是一种封装，封装就意味着拒绝修改你只需首先明白，设计模式，是一种“带着脚镣的舞蹈”；然后进一步思考为什么需要这些脚镣。想通了就好了。 最后，我还是强调“实践”，如果想要更好的理解第二条唯一有效的方法，可能就是实践了。这就是我学习设计模式的心得，希望对更多人有用（至少对我有用！）
