关于类爆炸的问题

[xue780616]

可能是由于设计者对面向对象设计经验的缺少，也可能设计者是一个刻板的教条主义者，结果出品了一个很不理想的设计，其中可能就体现在类的数量爆炸的问题。
类爆炸的现象已经发生在我们的软件系统中了。比如我们某期的系统中各种模块文件的数量已经达到一千多个了，虽然比起操作系统这样的系统来说，由一千多个模块组成的系统不算什么，但是我们目前的软件团队维护这么多的模块真的是有些吃力。由于我们使用的是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使用者请勿随意理解。这里有语言差异。）

[hjyhb]

说得很实在，经验之谈啊！

[xue780616]

使用面向对象设计技术会产生良好的系统，但是，类是面向对象中的东西，那么类爆炸也必然是使用面向对象的产物，这是不良设计导致的。
我们有的程序员有些过于遵守规范而显得有些刻板了。举个例子。某个程序员做了一个类A和一个类B，实体B是实体A的载体（规范中要求每个实体都要对应一个类），类A提供了一个修改自身的方法，当实体B的某个属性改变时必须要改变实体A的某个属性。我看了源代码，发现一条SQL语句就可以解决这个问题，但是这个程序员为了用类A的修改方法，在类B中写了一个循环，先找出所有属于实体B的实体A，并创建类A的实例，然后调用类A的修改方法。代码不但冗长还效率低下。这个程序员有自已的理由去那样做，理由1是上面领导制定的规范要求这样做，理由2是这是一种面向对象的应用，因为类A已经提供了修改实体A的方法，别人就应该重用这个方法。一切讲究重用。
我想提出的是，如果重用这个方法即不使代码简洁又不能提高效率而且还造成强烈的耦合，为什么还要重用它？在面向对象中，大家知道类的构造函数是用来做什么的吗？重载方法又是为什么吗？为什么一个类可以有多个不同的构造函数？不同的构造函数是为了达到不同的目的，而不仅仅是为了实例化一个类。方法的重载也是为了实现不同的目的。当类A提供的方法不能很好的完成任务时，我们就应该舍弃它或者重载它。如果规范要求必须类B调用类A的方法（这个“必须”很值得疑问）时，那么应该在类A中提供不同的修改方法以使设计合理。类A可以有这样的两个方法：方法1（以实体A自身的引用为参数）,方法2（以实体B的引用为参数）。
关于重用。
我们现在设计系统一直想达到重用的目的。但是考虑我们所做软件的性质，我们对系统组件应该达到什么样的重用程度。我们的组件是不是要发布出去供第三方二次开发？我们的组件是不是每年能达到2次重用？业务组件和与业务无关的组件重用的能力是不是有很大区别？我们不同的客户的业务规范是不是相差比较大？
由于我们现在对业务抽象的不到位，设计出来的类的粒度控制的不够好。业务相关和业务无关的对象的分离做的不够好，因此，实现组件甚至一个子系统的重用是很难的，只能为不同的客户去修改现有的代码，这显然不是重用，而是维护。我们的代码一年连一次重用的机会都没有。
关于创新。
如果没有创新的设计，后果是可想而知的，不管我们了解的业务再多，我们总是用最原始或者最笨拙的设计去实现业务。这样我们对业务了解的越多，系统做的越大，代码就越混乱越不稳定。能达到将就凑乎的使用已经是不错的了。当硬件技术飞速发展的时候，软件技术却落后，结果是什么？那么，在我们公司，业务和技术，哪个是硬件哪个是软件？当所有程序员都意识到争当项目经理和项目组长可以不去编写程序而待遇却提高了时，结果是什么？设计需要创新，了解业务却是一种带有明显的“被动”特征。用户不告诉你他的业务规则你就不知道，告诉你，你就知道。当用户停止提供需求时，这段时间内，需求调研人员应该做什么工作？是不是留下了大量的需求文档，是不是去抽象业务规则了？需求调研人员是不是能发现不同客户的不同业务之间的相似性为设计人员提供指导？
我们无法为客户去创新业务，但我们应该去创新我们的设计。一个软件的设计很难保持三年不变，如果三年后还不能有所创新而发生变换，那就落后了。为了适应新的形式，微软敢于修改自己的操作系统的内核使系统升级。不升级意味着失去财富，而升级时难免要修改部分内核。那么，应用创新技术付出的代价大还是保持原有系统不变的受益大？我们要考虑新系统生产时的阵痛和它以后带来的长远利益。
公司的人员流动的特征我们是否加以分析了，流走的是什么的样人，进来的又是什么样的人。这些人的技术能力、性格、悟性又是如何？我们拥有了许多安于现状不具创新的老员工，我们该怎么对待他们？如果一个员工的性格激烈但悟性良好能有创新，我们是不是排击他了？兢兢业业、按部就班、任由指挥是不是就是一个优秀的员工？
一个公司，各种性格的员工的存在应该有一个比例。全部都是不安分的创新者是不好的，充斥大量的安分守己、明哲保身、上面怎么说下面就怎么做的员工也是不好的现象。公司员工的性格和悟性的分布应该象一个波浪一样，有浪头有浪波，这样才能形成巨浪。
关于沟通。
公司越大，我发现员工之间的沟通越差。当我们还是一家小公司的时候，我可以认识所有的人，现在仅能认识个别几个人。沟通，不是由领导来强调下面的人去做的，而是由领导来启动和带动的。所谓“领导”两个字，就是“领”和“导”，什么意思？大家自然知道。如何才能称得上一个领导，他必须具有领头和导向的作用。各个部门的领导肩负着不同的“领导”。技术领导，他的技术是不是一定要强？若不强，是不是他能通过沟通的艺术来让下面的人服从？
沟通是一个大的问题。比如我早已经应用过一个比较好的数据库设计模型，但是新项目的设计者从来也没有咨询过我是怎么做的，结果他自己搞出一个很糟糕的数据模型。沟通是一个双向过程。被动的沟通与主动的沟通的效果自然是不同的。我们现在缺乏主动沟通，就是被动沟通都不能好好的参与。所以，沟通出现了“推模式”和“拉模式”。举个例子，我有些编程技巧放到公司网站了，很少有人去用主动的看，如果他主动去看了，这种行为模式称作“拉模式”。为了让更多的人知道我的技巧，我只能主动把技术文章发到每个人的邮箱里，我的这种行为模式是一种“推模式”。我把技术文章推到每个人的邮箱里了，那么接收邮件的人是不是“拉过来”看一眼？我发现，有一部分人是从来不看的，技术人员也不看。到底为什么不看？看不起我的文章还是太了解我而觉得没有必要看？他的心态我没有办法了解，总之，沟通是有障碍的。
“聚集”沟通需要大家坐在一起去探讨某些问题，但这可能会浪费参与人的时间。因此我一直以为“推模式”的沟通还是可取的。使用邮件来沟通，想看则看不想看就不看，尊重接收邮件的人的参与意识。但是发邮件会引来一些误会。一部分人会把你的邮件当作垃圾，心里不喜欢你给他发邮件但又不能说出来。一部分人会认为发邮件的人脑子有毛病或者出风头，我觉得应该让每一个人都摆正心态：尊重发邮件的人。历来都有“枪打出头鸟”的现象，人在浪头上，难免遭遇不恰当的言语。因此，永远低调和保持沉默便成为一种人生哲学。激进主义是用来推动社会前进的，保守主义是用来维持社会稳定的。我们允许这些同时存在。
由对事演化到对人。
当我们探讨问题时一般都是本着“对事不对人”的态度的。对于言者也许是这样的心里，但听者可能认为言者就是“对人不对事”。我们没有办法使他消除那种心里，因为那是他的性格使然。但是我们希望每个人都心胸开阔一些。
在探讨关于类爆炸的问题时，我说了一些题外话。
当我和一些同事在探讨设计中的缺陷时，发现大家的眼睛都还是明亮的，知道问题所在。不幸的是，几乎所有的人保都持沉默而不将问题暴露出来。当我暴露问题时，会得到个别人的善意的奉劝：“不要去做”。

[wwwxing]

牛人呀！

来我公司吧，钱不是问题，你开个价！

[xue780616]

说说软件公司的真真假假

[SeekTruth]

不错，确实不太好把握.