关于类爆炸的问题
可能是由于设计者对面向对象设计经验的缺少,也可能设计者是一个刻板的教条主义者,结果出品了一个很不理想的设计,其中可能就体现在类的数量爆炸的问题。
类爆炸的现象已经发生在我们的软件系统中了。比如我们某期的系统中各种模块文件的数量已经达到一千多个了,虽然比起操作系统这样的系统来说,由一千多个模块组成的系统不算什么,但是我们目前的软件团队维护这么多的模块真的是有些吃力。由于我们使用的是VB,这还导致另一个问题,VB能装载的文件总数是有限制的,最后用户提出了新的需求需要新的模块来完成实现,系统却已经不允许加入新的模块了,最后不得不对系统进行拆分或者对某些模块进行合并。
类爆炸的直接原因是设计者对类的抽象粒度没能把握好,只要两个事务有所差别就用不同的类来设计。粒度能多小就做多小,以为这样可以减少耦合。事实是如此吗?最近组长让我写一份设计问题,他已经规定了设计文档的规范和大纲,规范中说“本系统编码使用了三种类:界面类、实体类、记录集类,并调用了公用模块中相应函数”,这可能是他从别的设计规范中继承抄袭过来的。但是我最后提交的设计文档没有实体类和记录集类,组长问我为什么没有这两种类,我说我不需要这两种类,我这个功能一个界面就可完成了。但是他觉得,如果我没有那两个类就应该在设计文档中说明没有那两个类,我说我的设计文档中没有描述那两个类就表明我没有那两个类,而不需要在文档中说明“实体类,无;记录集类,无”。
如果每一个功能的完成都必须设计成“界面类、实体类、记录集类”这三种类来联合完成,我们就陷入了教条主义的深渊中。曾经和某个项目经理探讨过,“a=c与a=b=c”的取舍问题,我的观点是根据具体情况来决定是使用“a=c”的结构还是使用“a=b=c”的结构,他的观点是每个功能都一律使用“a=b=c”的结构,这导致我很郁闷。为什么要在很简单的情况下,本来可以直接就让“a=c”,何必非要加一个中间件“b”,通过“b”来让“a=c”?不是我不知道“a=b=c”的结构的用意,而是我觉要根据具体情况来应用。我们的系统的类爆炸就是因为不分优劣一律使用“a=b=c”的结构而爆炸的。对于面向对象的初期使用者来说,总会津津乐道他在系统中实现了面向对象的设计,尽管那个设计比较糟糕。其实这位项目经理只是给了一个系统的规范文档而已,至于说是他设计了系统的架构,那还远远谈不到。系统中有什么类,类如何创建,类如何组织,类之间如何通信,他都没有做。只是在文档里说了“本系统编码使用了三种类:界面类、实体类、记录集类,并调用了公用模块中相应函数”,一句话了事。系统中到底有多少类,他不知道。
我在阅读设计专家关于面向对象设计和设计模式的文章时,这些专家一再强调要谨慎使用面向对象和设计模式,否则后果就是苦果。我在应用面向对象时一向比较小心,一步一步的学习使用,而不是一步到位,毕竟我是个初学者。
再举一个例子。我们的系统中有一个连接类,大家都知道这个类是用来连接数据库的。不过我想很少有人知道为什么设计者要设计出这样一个类来。是因为他刚刚读过设计模式中有一个“单例模式”。对于我们现在的这个系统来说,使用一个数据库连接对象就可以了,设计者为了避免每个程序员都去创建新的数据库连接,就使用“单例模式”设计出一个连接类来。“单例模式”的用意就是某个类的实例在整个系统中只能有一个实例存在。比如我们用的windows剪贴板,在整个系统中只能有一个剪贴板,大家都不会去new一个新的剪贴板出来。
我感到非常的郁闷,在一个公用模块里申明一个系统变量connection就可以了,告诉大家这个对象是我们的数据库连接对象,大家都用这个对象,为什么再来一个clsConnection类对connection重新包装一下?,这反而就有问题了,我可以new出无数个clsConnection的实例,没有达到“单例模式”的用意,因为在clsConnection类里没有提供静态方法来总是返回系统中已经存在的连接对象,这成了“多例模式”了。也许设计者的另一个用意是要使用设计模式中的“简单工厂模式”。不过,不管是想练习什么模式,对于一个connection根本没有必要再包装了。这好比我们有一个系统级变量,为了避免大家都去申明这个变量就用一个类来包装这个变量。那么系统中已经存在这样一个类,为了避免大家乱用这个类,就再来一个类来包装这个类?层层包裹下去,怎么才算安全?(这里的例子是应用VB做的系统,JAVA使用者请勿随意理解。这里有语言差异。)