成也面向对象，败也面向对象

我一直不敢尝试面向对象的设计，因为自己掌握不好，没有那个水平，一直觉得设计和实现的差距实在是太大了。

我是离开微软后，才学习设计模式的。我记得在微软开发MSN Space的时候，使用Visio画了一个流程图，把思路表达的很清晰，代码也是按照这个流程写下来，就是最常见的Manager static DAL类，Service类封装了Manager，没有使用任何接口和设计模式。MSN Space自从第一次发布，就没有发生过rollback事件，后来随着需求的变化，又修改了当时的代码，但仍旧沿用最早期的流程而没有使用接口。

 

 

我发现往往一个好的设计，在没遇到特殊情况的时候是很美的，但是一遇到特殊情况，就变得很丑陋，如果能想到更好的解决方法，那倒还好。可是如果想不出来好的解决方法的话，那也就只能丑陋下去了。

 

是我自己的能力和经验不够？

 

 

在很多架构师的脑海里，架构设计就是设计模式，面向对象就等同于接口，等同于抽象，甚至把一个实体类也抽象成接口，而实现类却分散在不同的项目文件中，类的命名很长很相似，一不小心就找错了对象，对于功力不深的程序员来说，简直就是一场噩梦。

 

 

那天晚上加班到1点多，和同事闲聊了一下面向对象，同事举了一个例子：客人要求做一个小板凳。如果你是架构师，你会怎么考虑这个设计？

 

 

我敢肯定，很多架构师会这样考虑：这个小板凳能给小朋友坐、小朋友长成青年后也能坐、长成老年后能像轮椅那样也能坐。于是，一个很简单的设计就被复杂化了，人力成本、时间成本全部翻番。

 

 

现实中，“可扩展性、应对变化、代码复用”往往被很多架构师肆意夸大，夸大到忽略了原始需求的程度。不论什么设计，都要考虑日后的扩展，这样一来，简单的事情变得复杂，成本也提高很多。有同事嘲讽的说：“架构师不这样设计，怎么能体现出他的设计水平？！”

 

 

这个现象不是发生在某个架构师身上，而是一种普遍的现象，就像邪教一样毒害了很多爱好编程的孩子。

 

 

最后，说一下我个人的想法。

 

1） 面向过程、面向对象各有其优点和缺点，合适的才是最好的。

 

 

2） 面向对象中的设计模式是弥补语法的缺陷而产生的，随着语法的不断变化，设计模式也会变化，不能硬套23种设计模式。

 

 

3）“好的面向对象设计是那些可以满足应对变化、提高复用的设计”，这句话尽管说得没错，但是请牢记：设计的重中之重是满足当前客户的需求，至于“应对变化、提高复用、可扩展”等等那都是可有可无的。