我一直不敢尝试面向对象的设计,因为自己掌握不好,没有那个水平,一直觉得设计和实现的差距实在是太大了。
我是离开微软后,才学习设计模式的。我记得在微软开发MSN Space的时候,使用Visio画了一个流程图,把思路表达的很清晰,代码也是按照这个流程写下来,就是最常见的Manager static DAL类,Service类封装了Manager,没有使用任何接口和设计模式。MSN Space自从第一次发布,就没有发生过rollback事件,后来随着需求的变化,又修改了当时的代码,但仍旧沿用最早期的流程而没有使用接口。
我发现往往一个好的设计,在没遇到特殊情况的时候是很美的,但是一遇到特殊情况,就变得很丑陋,如果能想到更好的解决方法,那倒还好。可是如果想不出来好的解决方法的话,那也就只能丑陋下去了。
是我自己的能力和经验不够?
在很多架构师的脑海里,架构设计就是设计模式,面向对象就等同于接口,等同于抽象,甚至把一个实体类也抽象成接口,而实现类却分散在不同的项目文件中,类的命名很长很相似,一不小心就找错了对象,对于功力不深的程序员来说,简直就是一场噩梦。
那天晚上加班到1点多,和同事闲聊了一下面向对象,同事举了一个例子:客人要求做一个小板凳。如果你是架构师,你会怎么考虑这个设计?
我敢肯定,很多架构师会这样考虑:这个小板凳能给小朋友坐、小朋友长成青年后也能坐、长成老年后能像轮椅那样也能坐。于是,一个很简单的设计就被复杂化了,人力成本、时间成本全部翻番。
现实中,“可扩展性、应对变化、代码复用”往往被很多架构师肆意夸大,夸大到忽略了原始需求的程度。不论什么设计,都要考虑日后的扩展,这样一来,简单的事情变得复杂,成本也提高很多。有同事嘲讽的说:“架构师不这样设计,怎么能体现出他的设计水平?!”
这个现象不是发生在某个架构师身上,而是一种普遍的现象,就像邪教一样毒害了很多爱好编程的孩子。
最后,说一下我个人的想法。
1) 面向过程、面向对象各有其优点和缺点,合适的才是最好的。
2) 面向对象中的设计模式是弥补语法的缺陷而产生的,随着语法的不断变化,设计模式也会变化,不能硬套23种设计模式。
3)“好的面向对象设计是那些可以满足应对变化、提高复用的设计”,这句话尽管说得没错,但是请牢记:设计的重中之重是满足当前客户的需求,至于“应对变化、提高复用、可扩展”等等那都是可有可无的。