从“变”来理解设计模式

     对于设计模式，一直不怎么明白，看了一些简单模式就看不下去了。我觉得不了解这个技术或者的需求和由来的话就很难理理解和掌握。接触这些也有一些时间了，现在该写点自己的理解了。

     什么是开闭原则，什么是单例模式。我想很多人应该很快能够反映出来他们的概念。但是要问这些原则什么时候用？该用哪些？我想这些很多人就大眼瞪小眼了。原因就是不知道这些模式为什么会出现。当然我现在也不是很清楚。呵呵。

      这还要从大学课本的<软件工程>说起，那时候听的是一头雾水。根本不知道讲什么。后面做了些项目才理解了一些。软件工程就是研究用工程化方法构建和维护有效的、实用的和高质量的软件。 软件就是一个产品，有需求，设计，开发，使用，维护升级，到最后终止，也就是软件的生命周期。

     拿一个产品来说，厂家设计开发了一个产品。客户用了一段时间有问题了，要修理，那么怎么办？不能说一点毛病而导致换了很多东西，这个不行，如果设计合理，也即是软件设计 中的“高内聚，低耦合 ”，那么只需要修改很少的东西，而不会去影响和关联其他的东西，修理的过程就是维护 使用的过程。客户用了几个月，由于需求增加了，你又出来新的产品，旧的不能用了，那么不但客户不满意，就连厂家的产品也会没有市场，因为客户的成本和 厂家的成本都太大了。这就是设计开发中对于需求没有预见性，所以导致了设计不可以扩展升 级，每一次需求都要做一个新的产品出来，这简直不可想象。如果有预期的扩展，那么只需要在原来产品接口上进行扩展就可以了，这也就是软件的扩展升级 的阶段，这也体现了软件的可复用和灵活性 。直到有一天，这个产品没有办法扩展升级了，比如音频mp3要到视频MP4了，那么久只能进行产品的更新换代了，这时的mp3的生命也就终止 了。

     我们可以从上面的分析看出，软件其实是一个变化的东西，而不是开发完成就成了一个死东西。这就是从开发的成本来考虑，需要可复用，且复用也要灵活，尽量简单。那么那些设计模式跟这个是什么关系呢？对了，设计模式就是这么来的，我有这个需求了。我需要一个可适应变化的软件，所以我需要很好的设计，要用接口，继承，抽象，OOP这些具体的东西去设计分析，以便以后的修改升级和维护。而设计模式就是对这些设计的一些经验的积累，可以在设计的时候选择一些模式来满足自己的设计。

     理解了这些，就会知道，我如果只是一个小软件，用完就不用了，那就根本不需要去考虑什么模式和设计，怎么快能实现就怎么设计。而对于一个成本很高的软件，就需要认真设计，因为你不希望它以后不能修改或者修改麻烦，那需要成本。

      所以，看软件需要从一个“变”的角度去看，设计的时候要从“变”的角度去设计。也就是说设计时就要有预见性，没有对以后的预见性，不知道软件的可能需求，那么肯定就设计的是不能适应变化的软件。如果仅仅只是知道完成现在的需求，那么可以说一个架构师设计的结果和一个普通学生设计的结果是一样的。