面向对象还是面向流程

在看一些关于设计的书籍,总结经验,发现了这次南昌项目开发中设计的一些问题.

数据库类是按照数据库的对象和操作来划分类和行为的,暂时感觉没啥问题.

但是业务类就有问题了,开发的时候跟着流程走,所以感觉大部分是面向过程而非对象的.

现在开来,看了流程文档,对于业务类的分析应该做的事情是:从流程里面提取Actor,

然后根据每个Actor在流程中的操作添加相应的行为,而页面则应该是根据流程调用,相应类的行为.

如果采取这种方式对代码重用性和可扩展性和可读性还可以得到改进。

举个例子：业务树部分，在每个模块里面都有业务树操作，而且还分角色，一共就有十几个二十几个类似的方法了，

但是如果建一个业务树工厂类，采用工厂方法就只有几个方法了，方法根据传入的不同用户类型和sql语句的actionCode

再举个例子：如果设计用户为接口，继承它的有抽象类-管理员，普通用户类，而继承管理员抽象类的又分三种管理员。

这样分类的化，可以把原先登录，注册，用户增删改分别放入这棵继承树的不同层次，又减少了代码，又有可扩展性。

但是从项目管理的角度来说，心中存在着疑问：

如果用面向对象的方式来做，可能增加了对象的层次，所以增加了开发人员读懂设计人员设计的难度，

在开发协作方面似乎需要更多的交流，需要更多通过类图来表达类层次，而并非现在仅有的流程图。

我现在这么通过流程来设计业务类,对于前台开发两位人员来说道是方便了，只要根据流程图，调用功能模块的方法。

按照一些更大型的项目，采用的是按照机能来分模块开发的方式。

机能即为功能，似乎有点面向过程的味道，比如开发的模块也是分登录模块，某某操作模块，但感觉这些都该是对象的行为。

所以相应的这种开发方式在项目管理方面使用的是loc法，即代码行数来测试功能。

无论如何，面向对象是有它存在的价值的，如果一个开发人员对面向对象了解的透彻就能减少沟通的次数。

但是从面向对象的好处来说，减少代码量，同时减少出错的机会，又有扩展性，利远大于弊。