空间站

2.           高内聚是另一个普遍用来评判软件设计质量的标准。内聚，更为专业的说法叫功能内聚，是对软件系统中元素职责相关性和集中度的度量。如果元素具有高度相关的职责，除了这些职责内的任务，没有其它过多的工作，那么该元素就具有高内聚性，反之则为低内聚性。高内聚要求软件系统中的各个元素具有较高的协作性，因为在我们在完成软件需求中的一个功能，可能需要做各种事情，但是具有高内聚性的一个元素，只完成它职责内的事情，而把那些不在它职责内的事情拿去请求别人来完成。这就好像，如果我是一个项目经理，我的职责是监控和协调我的项目各个阶段的工作。当我的项目进入需求分析阶段，我会请求需求分析员来完成；当我的项目进入开发阶段，我会请求软件开发人员来完成；当我的项目需要测试的时候，我会请求测试人员。。。。。。如果我参与了开发，我就不是一个高内聚的元素，因为开发不是我的职责。

 

我们的项目为什么要高内聚呢？我觉得可以从可读性、复用性、可维护性和易变更性四个方面来理解。

1一个人写文章、讲事情，条理清晰才能易于理解，这同样发生在读写软件代码上。如果一堆代码写得一团乱麻，东一个跳转西一个调用，读它的人会感觉非常头疼。这种事情也许一直在写程序的你我都曾经有过经历。如果一段程序条理非常清晰，每个类通过名称或说明都能清楚明白它的意义，类的每个属性、函数也都是易于理解的它所应当完成的任务和行为，这段程序的可读性必然提高。在软件产业越来越密集，软件产业中开发人员协作越来越紧密、分工越来越细的今天，软件可读性的要求相信也越来越为人们所重视。

2在软件开发中，最低等级的复用是代码拷贝，然后是函数的复用、对象的复用、组件的复用。软件开发中最懒的人是最聪明的人，他们总是想到复用。在代码编写的时候突然发现某个功能是曾经实现过的功能，直接把它拷贝过来就ok在前面《如何在struts+spring+hibernate的框架下构建低耦合高内聚的软件》中我提到，我们现在的软件是在不断变更的，这种变更不仅来自于我们的客户，更来自于我们的市场。如果我们的软件通过变更能及时适应我们的市场需求，我们就可以在市场竞争中获胜。如何能及时变更以适应我们的市场呢，就是通过调整软件的结构，使我们每次的变更付出的代价最小，耗费的人力最小，这种变更才最快最经济。高内聚的软件，每个系统、模块、类的任务都高度相关，就使每一次的变更涉及的范围缩小到最小。比如评审表发生了变更，只会与评审表对象有关，我们不会去更改其它的对象。如果我们能做到这一点，我们的系统当然是可维护性好、易变更性好的系统。

那么，我们如何做到高内聚呢？就拿前面我提到的评审项目举例。我现在要为“评审表”对象编写一段填写并保存评审表的代码。评审表对象的职责是更新和查询评审表的数据，但是在显示一个要填写的评审表的时候，我需要显示该评审计划的名称、该评审计划有哪些评审对象需要评审。现在我如何编写显示一个要填写的评审表的代码？我在评审表对象的这个相应的函数中编写一段查询评审计划和评审对象的代码吗？假如你这样做了，你的代码就不是高内聚的，因为查询评审计划和评审对象的数据不是它的职责。正确的方法应当去请求“评审计划”对象和“评审对象”对象来完成这些工作，而“评审表”对象只是获取其结果。

另外，如果一个对象要完成一个虽然在自己职责范围内，但过程非常复杂的任务时，也应当将该任务分解成数个功能相对独立的子函数来完成。我曾经看见一个朋友写的数百行的一个函数，让人读起来非常费劲。同时这样的函数中一些相对独立的代码，本可以复用到其它代码中，也变成了不可能。所以我给大家的建议是，不要写太长的函数，超过一百行就可以考虑将一些功能分解出去。

与“低耦合”一样，高内聚也不是一个绝对，而是一个相对的指标，应当适当而不能过度。正如我们在现实生活中，如果在一个十来人的小公司，每个人的分工可能会粗一些，所分配的职责会广一些杂一些，因为其总体的任务少；而如果在一个一两百人的大公司，每个人的分工会细一些，所分配的任务会更加专一些，因为总体任务多，更需要专业化的分工来提高效率。软件开发也是一样，如果“评审计划”对象完成的业务功能少，并且不复杂，它完全可以代理它的子表“评审对象”和“评审者”的管理。但是“评审计划”对象需要完成的“对评审计划表的管理”这个基本职责包含的业务功能繁多或者复杂，它就应当将“对评审对象表的管理”交给“评审对象”对象，将“对评审者表的管理”交给“评审者”对象。同样，高内聚的可维护性好、易变更性好只能是一个相对的指标。如果一个变更的确是大范围的变更，你永远不可能通过内聚就不进行大范围的变更了。同时内聚也是要付出代价的，所以你也不必要去为了一个不太可能的变更去进行过度设计，应当掌握一个度。过度的内聚必将增加系统中元素之间的依赖，提高耦合度。所以“高内聚”与“低耦合”是矛盾的，必须权衡利弊，综合地去处理。综上所述，“高内聚”给软件项目带来的优点是：可读性强、易维护和变更、支持低耦合、移植和重用性强。

当我们分析清楚客户需求设计出用例模型以后，当我们分析清楚客户的业务环境制作出领域模型以后，当我们综合用例模型、领域模型和我们的聪明才智设计出一个又一个的类和它们各自的方法以后，当就在一切都准备就绪只欠东风的关键时刻，一个对象发出了撕心裂肺的怒吼——谁来创建我？！！！一个对象，不管拥有多么强大的功能，不管进行了多么精巧的设计，如果不能被创建，就如同韩信不能做将军，孙膑不能当军师，勾践不能回越国，刘备不能得荆州，一切一切的雄才武略都如废纸一张。既然“创建”对于对象如此重要，我们就来好好探讨一下GRASP3.           当我们完成了用例模型、领域模型、对象分析的设计，初步完成了对象设计和职责分配的工作，开始进一步细化的时候，一个我们不得不考虑的问题就摆在我们的面前——谁来创建这些对象？也许现在的你会觉得好笑，这也是问题吗？在软件实际开发过程中，谁需要使用某个对象，就去创建它就行了，有什么好讨论的。但是，我不得不说的是，如果你只是漫不经心地想要随意开发一套软件系统，仅仅是完成自己工作而已，你完全不用考虑创建对象的问题。然而如果你希望开发一套高质量的、低耦合的、封装性和复用性高的软件系统，你必须得认真考虑这个问题。为什么呢？因为系统中如果一个对象A那么为了降低系统耦合，提高系统的清晰度、封装性和可复用性，应该有一些通用的原则，以用于对象职责分配中，关于“创建对象”这类职责的分配。这些原则的描述就在GRASP1）   创建者模式的描述

如果以下条件之一为真（越多越好），则将创建类A如果有以上多个选项适用，通常首先条件1

2）   何时使用

在理解创建者模式的时候，我认为一个首先必须理解的问题是，在软件项目的整个过程中，它应该是在什么阶段使用。一个网友曾经发帖问我，他不清楚GRASP3）   为什么

我们做事往往有个习惯，凡事问个为什么。前面我提到，使用创建者模式的主要目的是可以降低系统的耦合。那么，我们在使用创建者模式的这几个建议的时候是如何降低耦合的呢？这一直是困扰了我很久的一个疑问，Craig Larman创建者模式告诉我们，如果系统中存在包含者容纳被包含者，或整体聚集部分，则包含者往往是被包含者的最佳创建者，整体往往是部分的最佳创建者。为什么呢？首先，这样的设计易于理解，可读性强。为什么这么说呢，我们用我们常见的单据与单据明细来说明吧。一张单据有多条单据明细，这些单据明细聚集于单据中，是单据的一个部分。对于某张单据，我们只有去填写这张单据，才会去填写它的明细。同样，我们要查看和修改这张单据的明细，首先肯定是找到这张单据。以上这些是我们在实际生活中大家都认同的管理单据的方式。GRASP尽管包含者往往是被包含者的最佳创建者，整体往往是部分的最佳创建者，但是在一个软件系统中，并不是所有类都有它的包含者或者整体。如果没有，谁应当创建它呢？记录者当然是另一个可以考虑的人选。仓库管理员管理进出库是ERP如果我们正在设计的软件类也没有记录者，这可如何是好？具有创建这个类所需数据的那个类可以考虑，那个类就是信息专家（什么是“信息专家”，我会在以后对信息专家模式的文章中详细描述）。在我们的设计过程中，很多类的创建是需要一些初始化数据的。最典型的就是我们的vo如果以上方法还不行，那我们就只有找使用者了。寻找使用者是我们创建类最常用的一种方法，但它的缺点也非常明显。正如前面我描述的，我们系统中对某个软件类的使用可能分布到系统的各个角落。当我们因为某个需求需要修改这个类的时候，我们根本不知道谁在使用它。正因为如此，这样的修改变得如梦魇一般，不断地搜索，不断地修改。我们前面说过，合理的软件构造是为了使我们的变更代价最小，而这样的变更将使我们的代价太大了，也许一个不经意的变更错误将造成我们的系统中一个意想不到的地方发生异常。故我们变更后测试的代价也就因此而增大。总之，寻找使用者作为创建者是我们业务分析阶段最后的终极选择。

4）   创建者模式是原则，不是准则

“创建者模式是原则，不是准则”难道“原则”和“准则”还有不同吗？当然。创建者模式是原则，所以我们在业务分析阶段应当尽量遵守。但创建者模式不是准则，因为并非我们的所有软件类都必须遵守。为什么这么说呢？随着项目的进行，我们的分析设计就不再停留在业务的分析上，各种具体的框架和技术将不断引进项目中，这时对象的创建就不一定符合创建者模式。比如，为了提高系统的性能和可维护性、更好地处理对象的创建与回收等复杂的问题，我们常常把对象的创建交给工厂，如spring

总之，合理地创建对象可以有效的提供可读性、降低耦合度、提高系统的封装性和可移植性，我们应当引起重视。