瞎说设计模式

水平有限只能瞎说，独孤九剑有破剑式、破掌式等针对敌人招式的破解之道，设计模式也是针对某一类问题的解决方案，独孤九剑到最后就是无招胜有招，设计模式到最后呢，是不是也是心中没有任何模式，但总能找到针对具体问题的合适方案呢？

设计模式是为了解决某一类通用问题而总结出的比较合适的解决方案，整个解决方案都是基于OO，每一种语言的特性不同，解决方式也有区别。说是合适的解决方案是因为，他们提供了灵活性、可重用性、可维护性，这一切又是建立在低耦合的基础上，模式能在需求变化时，灵活的适应新的需求，耦合度低，修改某个类时，不会牵连到不相关的类，这样就产生了易维护的代码

学习设计模式的方法：

       要认识到，设计模式并不是治百病的灵药，他们就是前人总结的解决某些问题的比较普遍适用的方法，因为他们的通用性，遇到具体的问题，你能得到比设计模式更好的解决方案，而不用管它是不是模式，是什么模式。

       一类问题通常有多个适用的模式，用哪个要自己考虑，从实际问题出发，结合现有的模式和语言的特性（如.net反射），找到新解决方案也是好的办法。

要想想那些解决方案为什么会成为模式，用模式为什么会比不用模式好,好在哪里，只有经过这些思考才能更深的了解设计模式，而不去套用模式而是从实际问题出发，去寻找合适的解决方案。

设计模式不是什么高深的东西，不应该去仰视他，而应该俯视，把他踩到脚下，他就是前人的总结，我们完全有可能比前人做的更好，因为我们面对的是具体的问题。

学习设计模式是为了解决问题，而不是为了学习而学习，我觉得学习过程是：

1、      看书，看实际例子，虚拟的那些没有太大帮助，道理谁都懂。设计模式就像画笔，只有到了画家的手里才能画出好的作品，而虚拟的例子就像是拙劣的作品，任何人都会画。

2、      体会，体会为什么要用模式，不用又如何。

3、      运用，一开始就套用，也不用管是否合适，这样就会发现问题，通过解决问题，才能加深理解。这时候不用去想“重构得到模式”之类，还没有到那一步。如果精通了，重构时也没有必要去得到什么模式，那样不是画蛇添足吗？本来问题已经完善的解决了，还要模式做什么呢？

4、      体会，体会设计模式的本质，他们共性的东西，为什么会产生设计模式，改进设计模式。

5、      融合，融合你知道的模式，遇到问题想解决方案，而去理会它是否是模式。（无招胜有招，哈哈）

整个是曲线上升的过程，要反复的体会、运用。不要掩盖自己的缺点，要暴露出来，这样才能提高。

如果说设计模式都体现了几条设计原则（OCP、DIP等），那么设计原则又是什么的体现呢？因此要思考些本质的东西，而不要只看表现，设计中没有任何东西是死的，如果要把这些看死了，认死理，就没有必要在看设计模式了。

       只是有些公司很短视，经常看到要求精通某项新技术之类的招聘信息，其实只要不是脑子有问题，给一个月的时间，基本上都会掌握那些所谓新技术（当然水平也一般，但又有多少用到更深的东西了？），但是要些出好的代码却不这么容易。

       据说，有干了几年的程序员还在写垃圾代码，这些人可能一直在追新技术，出来一个学一个，可是好多重要的东西都丢下了。我以前也一直紧跟MS脚步，现在已经觉得那样没有什么意义了，好多东西需要沉淀。前一段时间想去一家公司，我同学正好负责另一个部门的招聘说不要三十岁以上的，对这家公司的印象大大折扣。

为什么要用设计模式：

我认为是为了写好的代码，好是指：能灵活适用需求，易于维护，最后是重用。设计模式不是为了解决技术细节上的难题，如修改一个语句的bug，模式对这些没有帮助。发展到今天，做应用开发的，已经很少有细节上的难题了，遇到问题可以去MSDN，google，去看相关的开源项目，再不行，请教某个高手。这样一来，培训几个月，谁都可以去写程序了。

但是要想写好，就必须要学习设计模式，学习设计，这需要自己用心体会，实践。不能通过MSDN，google，请教高手得到提高。必须经过自己的努力。

做开发，可以不用设计模式，但你要知道设计模式所带来的好处。这些好处在维护旧代码，需求改变时最能体现，见到垃圾代码真有去砸机子的想法，而设计好的代码就好多了。

设计模式主要是解决设计中的僵化性，脆弱性，粘滞性。这些特性都是在变化中体现的如果没有变化，也就没有了运用设计模式的基础，也没有必要用OO了。

设计模式的语言相关性：

设计模式主要用到的是抽象、多态，抽象和多态可以用继承实现，也可以用函数指针实现（.net委托），所以有些模式既有继承的实现方式也有委托的实现方式，哪种实现合适和语言特点、问题相关。还可以用配置文件、反射（.net）机制实现设计模式和设计的灵活性。

设计中的几个问题：

设计模式更注重于可复用的结构设计方案，而框架更注重具体问题的设计和实现。

针对接口编程，而不是针对实现，这就要求在类层次的顶端是接口或者抽象类。

让类的调用者去时刻记着去检查错误码是愚蠢的想法，因此要尽可能的使用异常。

我一直觉得设计模式，设计，一直在解决耦合性的问题。如果达到了合适的耦合就是很好的设计。（不知道对不对）