Desing Pattern

近来由于工作上的需要,用了两个来月的时间,对UML及设计模式一些书籍进行了阅读.让我颇有受益,不过还得继续努力. 一个月前离开了一家公司,当时公司准备做B/S结构的开发,以前一直用PB开发.对于PB来说, 只是一种快速开发工具,并非面向对象的语言.在这次开发中,我负责计费系统的程序设计及编码. 这其中一个很有意思的"插曲".由于计费系统的算法比较复杂,而且算法是多变的,以前在PB中实现是在四个userobject中完成的,便这样对于程序的健壮性,可维护性是特别差的.基本上程序是牵一发动全身,程序之间强藕合.所以鉴于这种情况,我决定在新的版本里,不采且这种方式来实现,对于算法这块,我采用的是stratege和bridge两种设计模式相结合的方式来实现.并且我在 rose中画出了class diagram (粗略的),当我把这种设计思路和我们当进软件部副总(不懂面向对象,只是熟悉PB)给他讲时,他的一番和我的辩解让我真是无可奈何的直摇头.在他认为,没有必要对算法分现那么的类来,同时他坚持在程序中多用些IF ,case语句就可以达到我同样的目的.我对于他的这种回答不知让我说他什么好.面向对象(好的设计)的好处之一在于可以使程序有更好的健壮性,可维护性,可扩展性.当然,多用些IF,CASE语句的确是能完成这样的功能.但试想下,如果用户需求变了,需要增加一个算法,那又如何做呢,在这两种设计中:PB中,在userobject增加一个函数,(这违背了开放封闭的原理),同时还要熟悉程序中函数是如何调用的,在JAVA中,我只需要派生一个新的算法类就可以,只需要客户端直接调用就可. 当然我当时对面向对象的设计理解的还是很肤浅.有时也决的为何不直接调用类中的函数, 这样很省事,非得在中间要加上一层接口.到现在我才有点明白针对接口编程的确是很有道理的对于客户化程序我们不用去了解业务实现细节,同时业务层的改变也不会影响上层的调用,这样就达到了从视图层,业务层,数据层由上至下的松藕合了.所以面向对象设计提出了三点基本的要求: 1:针对接口编程

2:将实现和抽象进行分离,在设计时优先考虑的是类的是类的组合,而不是继承.

3:将变化的为进行封装.