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