是什么限制了我们面向对象（的开发）

[LoveCherry]

今天看到CSDN中的两个讨论贴，一个帖子在说技术经理不允许团队成员使用面向对象的方式开发程序，另外一个帖子（找不到地址了）说某个团队成员在尝试使用面向对象的方式设计和写程序，但是遭到了其它程序员的鄙视。

或许你也在郁闷，为什么跳槽了这么多公司，想学一些面向对象的开发方式，怎么弄来弄去都还是基于对象（基于面向对象框架的开发）的开发呢？我想，其中的原因可以从几个方面来说：



公司



1. 公司性质

如果公司本身就是一个面向小客户（比如制作小网站）、面向外包的小公司，或者公司并不小，但是公司的开发团队仅仅属于公司的后勤部门，开发的产品并不能给公司带来利润等等原因都可能使得开发向简单化、过程化发展。

2. 管理团队

就像前面那个网友说的，技术经理不允许面向对象开发。可能技术经理看的是项目的维护性、看的是项目的进度，而没有看到项目远期的维护性和扩展性。也可能技术经理并不反对，而他的上司是非常看重眼前利益的，技术经理也无能为力。管理团队的任何一个层次都可能会对开发模式产生影响。



项目



正因为有前面说的那些公司，导致项目往往有以下的特点：

1. 项目进度非常赶并且一个接一个。我们除了能运用成熟的开发流程、框架之外哪里还要时间思考过多的问题呢？

2. 项目的可维护性和可扩展性不重要，甚至有的项目要求就是可维护性差、可扩展性差（公司希望项目卖出去之后从客户那里获取更高的维护费用）。

3. 项目非常小，而且偏向于网站。由于网站以数据为中心、业务逻辑较少并且注重性能的特殊性，要在这样的项目中推行面向对象的开发确实是实际效果比较差的。



团队



由于公司的性质或项目的性质就导致了产生了这样的一些团队：

1. 开发人员水平参差不齐。这里的水平包括基础、经验以及学习能力。由于面向对象需要开发人员有一定时间的OO思想的积累，对于这样一个团队，即使推行了OO，不知他们之间的协作会有什么问题呢？

2. 开发人员没有良好的OO背景。有些人以前是做ASP的，有些人以前是做VB的，可能对于做ASP.NET的开发人员来说有ASP和VB背景的人比较多。这样的话就会导致难以整体转化开发思想，即使转换了，代价也比较大。

3. 团队中没有对OO经验丰富的人，或者从组织结构上说，团队中并没有设计师的角色，项目经理手下都是普通“老百姓”。

4. 团队的学习气氛不好。很多团队死气沉沉，上班-下班，团队中也有很多年龄较大的程序员，要在这样的团队中推行新的开发思想确实很难。

5. 团队过于庞大。

6. 更极端的情况是，团队中所有人都是只会增删改的初级程序员，而项目经理完全不懂技术（招聘的时候只求工资低，面试只看是不是会使用控件进行增删改）。



技术



如果团队已经习惯了基于过程化的开发，那么要向面向对象开发进行转换还需要解决非常多的关键问题：

1. 持久化

关系型数据库和领域（业务对象）模型之间有比较大的差异，我们不得不依靠一些ORM框架来实现业务对象的持久化，ORM框架的性能、ORM框架的学习难度、ORM框架的可靠性都是在把框架应用到项目中需要考虑的问题。

2. 对象呈现

业务对象往往是相互关联的复杂结构，而UI往往是平面化（一维或二维）的趋向于关系型数据库一种表现方式，这个转换过程可能会很复杂，所谓的面向对象是不是没事找事把关系型数据转化为业务对象，再把业务对象格式化成UI喜欢的数据源（比如DataTable）呢？

3. 性能

前面说的2点都可能会产生性能问题。首先，表现层是否需要完整的业务对象，其次，是否需要从数据库中获取完整的业务对象。如果界面上只希望显示10K数据，而ORM框架却从数据库中获取了100K数据并且把它们都传给了表现层，是不是不太合理？如果说还引入了分布式的话，那么网络上传输的代价就会更大。从小的层次来说，面向对象本身就或多或少降低了性能。



主观原因



如果上述这些客观原因都不存在的话推行面向对象开发还有难度，那么可能还有一些主观原因存在：

1. 给自己很多不使用OO的理由。拿到项目了，总是想项目太小、进度太紧，算了这次不尝试OO了，以后遇到其它项目再来尝试吧。没有小项目的思考，怎么能遇到大项目而不慌乱呢？

2. 没有责任心。希望尽快结束项目，在项目可维护性变得很差连自己都不想维护的时候往往也是我们引咎辞职的时候。

3. 没有转换的动力。大家沉浸在一个不错的过程化开发过程中，宁可愿意把维护的工作留给新来的同事也不愿意去尝试新的开发过程。



理想的环境



你或许一直在寻觅这样一个环境：

1. 不错的公司，从事大型企业级软件的开发，有着经验丰富并且开明的项目经理。

2. 项目周期长、项目大且复杂，客户对项目的维护性和扩展性要求比较高。

3. 团队中不乏经验丰富的构架师和OO达人，团队讨论气氛良好。

4. 有完整的基于面向对象的解决方案，开发流程非常正规。

说实话在国内确实很少。很多时候，我们能看到的也仅仅是在表面上非常好，而在真正的开发过程中发生扭曲的环境。



说说我们的情况



1. 项目是为公司的产品服务的，团队的产出不会给公司带来直接利润，也不是公司的技术核心。

2. 团队不大，团队成员水平相差较大，以我为90分的话，那么团队中有20分的，也有80分的。几乎所有人都有非OO语言的背景，也可以说是由于ASP.NET而接触C#的，而不是由于C#而基础ASP.NET的，导致基本没有任何OO概念。

3. 项目都是不超过2个月的超小项目，甚至会有很多2天的“项目”（其实就是做一个页面）。项目基本都是以数据为中心的网站，而且对性能要求非常高。项目对时间要求非常苛刻，说好这个时间点连一天都不能晚。

基于这些情况，我思考了很久还是决定以一套学习曲线低的构架、流程来开发这些项目。不过，这并不是说我们永远就是过程化开发了，我会在时机成熟的时候把一套合适的面向对象开发流程推给团队（请注意这里的“时机成熟”以及“合适的”两个词）。个人认为，只要有明确的开发方式、相对成熟的开发框架，上面的3点并不能挡住我们OO的脚步（“我们”仅指我们团队），只不过，我还在寻找一个合适的切入点。



讨论



基于这些客观或主观原因（其实，往往这些原因是交错的，因为这个也就产生了那个），真正面向对象的开发（包括完善的开发流程）在国内大多数公司（包括我们公司）中难以推行，（由于快下班了，我并没有过多去思考改善的方法）请大家讨论…………（本文只是总结一下现况，并不表达过程化开发和面向对象开发的优劣）

[lextm]

国内公司做的软件，多数还是集中在面向过程开发。例如底层的驱动，嵌入式。能够使用OOP开发上层应用软件的单位本来就不多。这个是公司不太熟悉OOP的问题。我现在所在的公司就是如此，开发人员编码规范还是C的那一套，定义东西还是一串API，根本没有对象。

另一个确实是人员素质问题。读得懂UML的人不多。

实践中我的感觉是，很多人想使用OOP，但是OOP不是一个纯粹的设计问题，很多后期遇到了问题的时候需要重构，设计模式知识。但是懂一点OOP的人，又不是很懂重构和模式，所以做到一定阶段不能抛掉错误的原始设计来改善代码质量。

总之OOP还是需要时间累积的，不是一蹴而就的。国内高校教育也不重视OOP，基本上从教育开头就有问题。

[octverve]

是教育问题，是教学生的教师本身就对“面向对象”只停留在书本上，更可以说是，他们在误导学生｛为了钱，现在的人什么QDS都干，误人子弟～～｝

强都改变环境，弱者适应环境，就是这么简单～～

[jeremyyang824]

民心所向 没的商量~~

[俩定]

顶一个，感觉就是现状。

[sunlovesea]

有空过来看看

[LoveCherry]

更多讨论见 http://www.cnblogs.com/LoveCherry/

[xuyiazl]

LoveCherry 斑竹 貌似经常性的打广告~~~~~

不过讨论性的东西确实能学到很多东西

[wanghui0380]

呵呵，这个问题嘛，是个过程问题。
就像cmm评级有1到5，5个等级。

现在的问题是我们都太极端，要不就在第一级上，要不就在第5级上

老人们实际上都知道oop好，不过我们不愿意动！（到不是完全不动，我们更愿意渐变，而不是突变）
新人们言必称ajax，oop，模式。问题在于这些东西并不是你想要如何就如何的，这个要的是经验，要的是对传统编程的优点和缺点的一个正确的认识。哈哈，你不知道在传统编程里给一个既有的项目加一个有关联的新东西，有多麻烦！你就不会明白为啥要模式！！你不明白对一个关系型数据库的结构性更改，对项目有多大！你就不会明白为啥要分层

实际上就我个人理解，oo实际上是一种对需求更改的预判。一个东东如果变化快，他应该被oo掉，如果他影响范围大，应该尽量减少他的影响范围。

问题就在这里了：老人们对自己擅长的范围内的需求都是很明白的，我们知道那里是变化快的，那里是耦合强的。但是没有oo的年代我们一样过来了，我们有自己的应对方法，有属于自己的“设计模式”，更改他们需要付出的代价还是比较大的

新人们天天喊这oo，但实际上他们根本就不明白为啥要oo，结果是过分设计或者根本就不会设计，只会用现成的框架

所以我想的是：
1.需要一个知道为啥要oo，在那里要oo的人
2.你的公司要给你个过程，我们可以不一步到位！我们可以学cmm那样，先oo1，OO2-----最后OO5

[qq22345111]

顶

有的东西让我眼睛一亮，原来我还没睡醒啊

[benimaru8610]

郁闷，看半天没看懂，oo是啥啊？

[shiyulun1984]

顶

[SkyeyGarden]

要oo的开发,一般都要3年以上经验的人,对所有有一定了解,对系统也做得比较多,但这样得人在社会比较少人要或者给不起钱

[超级大笨狼]

常规的工作正如楼主所说没法OO,因为对象不清楚,需求在变化,还有就是怎么变化都是普通数据库项目,只能用面向数据库的办法最高效稳妥.

OO适合做些自己喜欢的一些高难度小题目,封装,组合是用的(继承多态基本没用)
OO更适合当玩具,因为坏了可以扔.构造可以复杂也可以有缺陷.

但是常规的工作中真的不适合OO.累呀!~~

OO可以用来做一些小的工具,算法研究,小游戏.

作为部门主管,我在工作中安排大家SQLHelper-->DataTable,业余时间出些OO的小题目玩.哈哈,这样就对了.

[lions911]

楼主高人，我是你忠实的粉丝。

[jiangshan1981129]

我们公司就是完全应用OO思想,多个人写出的代码基本上是一种格式的,很好维护

[fphuang]

的确现在大多数项目，只是完成了实力化操作

[liapply]

我觉得要看项目，小项目没必要OO，太麻烦了，
但是大项目我想就是你不想OO可能做到一半，你就要反回再从OO开始

[friky]

大学毕业一年多，这一年来，一直在学习OO的思想，学设计模式，可是工作上，全是面向过程的编码，要在项目经理的代码的基础上写，郁闷，想跳，怕还是这个样，作程员只是这个命了，我想只有年头到了，作到构架师这个级别了，才可能按照自己的想法写代码吧。

[rfxrt2]

哈哈，楼主说到我心里也

老是想把OO的思想用到项目里，发现要建立个抽象类或者接口都那么难，不知道哪里用得到，
我做的一个B2C网站，数据层用了桥接模式，简单问题复杂化，因为我想OO，结果还被批了呵呵

[yangjia21_2007]

我要哦哦