近日重新读了一遍<设计模式>,结合自己的开发，项目经验，谈谈自己的体会。
设计模式的目的：
1. 可重用性，开发人员常遇到的问题和解决问题的模式，自己可以拿来使用，拿来主义。
2. 公共词汇，现在大部分开发人员都认可设计模式，并都能领会其含义，这样便于开发人员针对问题的解决方案的沟通。
解决手段：
1.多用接口，少用继承。现在好多框架也提倡这个理念，java开发中尤是。
2. 增加一个中间类，例如：工厂，生成器，适配器，中介，代理，桥接，装饰器，访问者，解释器等。有的把对象的创建单独拿出来作为一个类，有的在使用对象用一个新类来间接使用。
3. 在开发中多使用语言的新特色，能简化编程。例如：泛型，泛型约束，LINQ，扩展函数。
4. .NET 技术本身就应用了很多设计模式，例如：WCF--代理。
结合自己现实项目，来具体谈谈。
首先不谈具体编程，从整个产品线来看设计模式。
产品线建设，产品开发如果应用设计模式的理念能使一团乱麻，无法解决的复杂问题豁然开朗。
先简单介绍一下产品线的背景：产品线包括一个集成平台和十几个子系统，集成平台需要集成一个或多个子系统。产品线分为三个开发小组：前端开发，中间业务开发，采集层开发。应用到项目中时集成平台需要根据实际需要生成不同的版本。
介绍了背景，第一个问题就出来了，子系统很多，要保证子系统正常运行，也要保证集成平台的运行，我们如何开发基础产品，开发步骤，开发原则？
第二个问题，随着项目的增加，如果保证各个项目集成平台的可维护性？各个项目的集成平台的升级问题如何解决？
让我们应用设计模式的一些理念来分析第一个问题。让我们先默念两遍“产品线”这个词，脑中应该会浮现出“工厂”，“抽象工厂”。
我们能不能用“抽象工厂”的概念来解决我们的产品线建设呢？
把三个开发小组看做三个工厂。他们需要遵循统一的开发步骤和设计规范。开发步骤和设计规范看做工厂接口。
把多个子系统看做产品系列。各个子系统需要遵循统一的产品规范。产品规范为产品接口。
例如：产品开发小组-GPS子系统前端 做为一个产品的创建过程。
产品创建完了，还有创建出子系统和集成平台。其实创建子系统和集成平台的过程可以用“Builder” 模式。把GPS前端，GPS中间层业务，GPS采集集成起来构成GPS子系统。GPS子系统，VES子系统，VMS子系统集成起来构成集成管理平台。
从设计模式中我们应该体会到，产品线建设首先要确定统一的开发步骤和设计规范，每个开发小组贯彻执行之。其次每个开发小组要对自己开发部分有个统一的设计，形成架构或者规范。这样在产品线创建过程中会流畅很多。其实现实非描述之简单，复杂的多。以上观点只是复杂的问题简单化。
第二个问题也很关键，如果解决不好，随着项目的增多，最后开发人员会疲于应付。例如发现一个BUG，或者解决了一个性能优化问题。如果解决多个项目同时升级。
我想到的是应用装饰器模式，核心平台创建完毕以后，各个项目在核心平台的基础上进行装饰，不要更改核心平台的代码。这样以后不论核心平台的升级还是项目的需求维护起来会简单一些。 千万不要一个项目一个核心平台,核心平台代码随意更改。