例子 耦合 软件工程_公共耦合例子 - CSDN
精华内容
参与话题
  • 一个优秀软件开发人员的必修课:高内聚高内聚 Java 软件工程 软件模式 一个重要的模式:高内聚。2. 高内聚(High Cohesion)高 内聚是另一个普遍用来评判软件设计质量的标准。内聚,更为专业的说法叫功能内聚,是...
     
    

    一个优秀软件开发人员的必修课:高内聚

    高内聚 Java 软件工程 软件模式    

    一个重要的模式:高内聚。

    2.  高内聚(High Cohesion

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

    1.可读性

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

    2.复用性

    在软件开发中,最低等级的复用是代码拷贝,然后是函数的复用、对象的复用、组件的复用。软件开发中最懒的人是最聪明的人,他们总是想到复用。在代码编写的时候突然发现某个功能是曾经实现过的功能,直接把它拷贝过来就ok了。 如果这段代码在同一个对象中,那么就提出来写一个函数到处调用就行了。如果不是在同一个对象中呢,就将其抽象成一个对象到处调用吧。如果不在一个项目中 呢,那就做成组件给各个项目引用吧。代码复用也使我们的代码在复用的过程中不断精化、不断健壮、提高代码质量。代码的复用的确给我们的开发带来了不少便 利,但是一段代码能否在各个需要的地方都能复用呢?这给我们的软件开发质量提出了新的要求:好的代码可以复用,不好的则不行。软件中的一个对象如果能保证 能完成自己职能范围内的各项任务,同时又不去理会与自己职能无关的其它任务,那么它就能够保证功能的相对独立性,也就可以脱离自己所处的环境而复用到其它 环境中,这是一个具有内聚性的对象。

    3.可维护性和易变更性

    在前面《如何在struts+spring+hibernate的 框架下构建低耦合高内聚的软件》中我提到,我们现在的软件是在不断变更的,这种变更不仅来自于我们的客户,更来自于我们的市场。如果我们的软件通过变更能 及时适应我们的市场需求,我们就可以在市场竞争中获胜。如何能及时变更以适应我们的市场呢,就是通过调整软件的结构,使我们每次的变更付出的代价最小,耗 费的人力最小,这种变更才最快最经济。高内聚的软件,每个系统、模块、类的任务都高度相关,就使每一次的变更涉及的范围缩小到最小。比如评审表发生了变 更,只会与评审表对象有关,我们不会去更改其它的对象。如果我们能做到这一点,我们的系统当然是可维护性好、易变更性好的系统。

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

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

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

    综上所述,“高内聚”给软件项目带来的优点是:可读性强、易维护和变更、支持低耦合、移植和重用性强。

     

    一个优秀软件开发人员的必修课:GRASP2)低耦合

    关键字: 设计模式       

    我偶然在googleyahoo这样的搜索引擎搜索GRASP发现,除了国外的网站,国内网站多介绍和讨论GoF而很少介绍GRASP,即使这少量的文章也讲解非常粗略。个人认为作为优秀的开发人员,理解GRASPGoF更重要,故写此文章。前面我在《 (原创)一个优秀软件开发人员的必修课:GRASP软件开发模式浅析》中介绍了使用GRASP的目的,今天允许我调换一下顺序,先从低耦合讲起,因为诸如创建者模式、信息专家模式的根本目的就是降低耦合。

    1.    低耦合(Low Coupling

    “低耦合”这个词相信大家已经耳熟能详,我们在看spring的书籍、MVC的数据、设计模式的书籍,无处不提到“低耦合、高内聚”,它已经成为软件设计质量的标准之一。那么什么是低耦合?耦合就是对某元素与其它元素之间的连接、感知和依赖的量度。这里所说的元素,即可以是功能、对象(类),也可以指系统、子系统、模块。假如一个元素A去连接元素B,或者通过自己的方法可以感知B,或者当B不存在的时候就不能正常工作,那么就说元素A与元素B耦合。耦合带来的问题是,当元素B发生变更或不存在时,都将影响元素A的正常工作,影响系统的可维护性和易变更性。同时元素A只能工作于元素B存在的环境中,这也降低了元素A的可复用性。正因为耦合的种种弊端,我们在软件设计的时候努力追求“低耦合”。低耦合就是要求在我们的软件系统中,某元素不要过度依赖于其它元素。请注意这里的“过度”二字。系统中低耦合不能过度,比如说我们设计一个类可以不与JDK耦合,这可能吗?除非你不是设计的Java程序。再比如我设计了一个类,它不与我的系统中的任何类发生耦合。如果有这样一个类,那么它必然是低内聚(关于内聚的问题我随后讨论)。耦合与内聚常常是一个矛盾的两个方面。最佳的方案就是寻找一个合适的中间点。

    哪些是耦合呢?

    1.元素B是元素A的属性,或者元素A引用了元素B的实例(这包括元素A调用的某个方法,其参数中包含元素B)。

    2.元素A调用了元素B的方法。

    3.元素A直接或间接成为元素B的子类。

    4.元素A是接口B的实现。

    幸运的是,目前已经有大量的框架帮助我们降低我们系统的耦合度。比如,使用struts我们可以应用MVC模型,使页面展现与业务逻辑分离,做到了页面展现与业务逻辑的低耦合。当我们的页面展现需要变更时,我们只需要修改我们的页面,而不影响我们的业务逻辑;同样,我们的业务逻辑需要变更的时候,我们只需要修改我们的java程序,与我们的页面无关。使用spring我们运用IoC(反向控制),降低了业务逻辑中各个类的相互依赖。假如类A因为需要功能F而调用类B,在通常的情况下类A需要引用类B,因而类A就依赖于类B了,也就是说当类B不存在的时候类A就无法使用了。使用了IoC,类A调用的仅仅是实现了功能F的接口的某个类,这个类可能是类B,也可能是另一个类C,由spring的配置文件来决定。这样,类A就不再依赖于类B了,耦合度降低,重用性提高了。使用hibernate则是使我们的业务逻辑与数据持久化分离,也就是与将数据存储到数据库的操作分离。我们在业务逻辑中只需要将数据放到值对象中,然后交给hibernate,或者从hibernate那里得到值对象。至于用OracleMySQL还是SQL Server,如何执行的操作,与我无关。

    但是,作为优秀的开发人员,仅仅依靠框架提供的降低软件耦合的方法是远远不够的。根据我的经验,以下一些问题我们应当引起注意:

    1   根据可能的变化设计软件

    我 们采用职责驱动设计,设计中尽力做到“低耦合、高内聚”的一个非常重要的前提是,我们的软件是在不断变化的。如果没有变化我们当然就不用这么费劲了;但是 如果有变化,我们希望通过以上的设计,使我们在适应或者更改这样的变化的时候,付出更小的代价。这里提供了一个非常重要的信息是,我们努力降低耦合的是那 些可能发生变更的地方,因为降低耦合是有代价的,是以增加资源耗费和代码复杂度为代价的。如果系统中某些元素不太可能变更,或者降低耦合所付出的代价太 大,我们当然就应当选择耦合。有一次我试图将我的表现层不依赖于struts,但发现这样的尝试代价太大而失去意义了。对于软件可能变更的部分,我们应当努力去降低耦合,这就给我们提出一个要求是,在软件设计的时候可以预判日后的变化。根据以往的经验我认为,一个软件的业务逻辑和采用的技术框架往往是容易变化的2个方面。客户需求变更是我们软件设计必须考虑的问题。在RUP的 开发过程中,为什么需要将分析设计的过程分为分析模型和设计模型,愚以为,从分析模型到设计模型的过程实际上是系统从满足直接的客户需求到优化系统结构、 适应可预见的客户需求变更的一个过程。这种客户需求的变更不仅仅指对一个客户需求的变更,更是指我们的软件从适应一个客户需求到适应更多客户需求的过程。 另一个方面,现在技术变更之快,EJBhibernatespringajax,一个一个的技术像走马灯一样从我们脑海中滑过,我们真不知道明天我在用什么。在这样的情况下,适应变化就是我们最佳的选择。

    2   合理的职责划分

    合理的职责划分,让系统中的对象各司其职,不仅是提高内聚的要求,同时也可以有效地降低耦合。比如评审计划BUS、评审表BUS、评审报告BUS都需要通过评审计划DAO去查询一些评审计划的数据,如果它们都去直接调用评审计划DAO(如图A),则评审计划BUS、评审表BUS、评审报告BUS三个对象都与评审计划DAO耦合,评审计划DAO一旦变更将与这三个对象都有关。在这个实例中,实际上评审计划BUS是信息专家(关于信息专家模式我将在后面讨论),评审表BUS和评审报告BUS如果需要获得评审计划的数据,应当向评审计划BUS提出需求,由评审计划BUS提供数据(如图B)。经过这样的调整,系统的耦合度就降低了。

    3   使用接口而不是继承

    通过对耦合的分析,我们不难发现,继承就是一种耦合。如果子类A继承了父类B,不论是直接或间接的继承,子类A都必将依赖父类B。子类A必须使用在存在父类B的环境中,父类B不存在子类A就不能使用,这样将影响子类A的可移植性。一旦父类B发生任何变更,更改或去掉一个函数名,或者改变一个函数的参数,都将导致子类A不得不变更,甚至重写。假如父类B的子类数十上百个,甚至贯穿这个项目各个模块,这样的变更是灾难性的。这种情况最典型的例子是我们现在使用hibernatespring设计DAO对象的方式,具体的描述参见我写的《如何在 struts + spring + hibernate的框架下构建低耦合高内聚的软件结构》一文。

    总之,“低耦合”给软件项目带来的优点是:易于变更、易于重用。
    展开全文
  • 一例看懂C语言程序中的内聚和耦合

    千次阅读 2018-02-28 15:56:11
     在软件工程中,模块的内聚和耦合是度量模块化质量的标准之一。内聚是指模块的功能强度的度量,即一个模块内部各个元素彼此结合的紧密程度的度量。若一个模块内各元素(语名之间、程序段之间)联系的越紧密,则它的...

    (一)原理篇

      (清楚相关原理的读者,请直接看第二部分示例篇)
      在软件工程中,模块的内聚和耦合是度量模块化质量的标准之一。内聚是指模块的功能强度的度量,即一个模块内部各个元素彼此结合的紧密程度的度量。若一个模块内各元素(语名之间、程序段之间)联系的越紧密,则它的内聚性就越高。耦合是程序中各模块之间相互联系紧密程度的一种度量。各模块之间联系越紧密,其耦合性就越强。模块间耦合高低取决于模块间接口的复杂性、调用的方式及传递的信息。
      在程序设计中提倡的是高内聚低耦合。所谓高内聚,是指模块是由相关性很强的代码组成,只负责一项任务,也就是常说的单一责任原则,这样的模块,无论从设计、实现还是阅读,都能体现出其保持专一性带来的好处。而低耦合,是指模块之间尽可能的使其独立存在,模块之间不产生联系不可能,但模块与模块之间的接口应该尽量少而简单。这样,高内聚从整个程序中每一个模块的内部特征角度,低耦合从程序中各个模块之间的关联关系角度,对我们的设计提出了要求。
      程序设计和软件工程发展过程中产生的很多技术、设计原则,都可以从内聚和耦合的角度进行解读。作为C语言程序设计的初学者,结合当前对于函数的理解可达到的程度,我们探讨一下如何做到高内聚低耦合。
      针对低耦合。耦合程度最低的是非直接耦合,指两个函数之间的联系完全是通过共同的调用函数的控制和调用来实现的,耦合度最弱,函数的独立性最强。但一组函数之间没有数据传递显然不现实,次之追求数据耦合,调用函数和被调用函数之间只传递简单的数据参数,例如采用值传递方式的函数。有些函数数在调用时,利用形式参数传地址的方式,在函数体内通过指针可以修改其指向的作用域以外的存储单元,这构成了更强的耦合,称为特征耦合,在这里,使函数之间产生联系的是地址这样的特征标识。另外,有两个函数可能会打开同一个文件进行操作,这也构成了特征耦合的一种形式。更强的耦合是外部耦合,这里,一组模块都访问同一全局变量,而且不通过参数表传递该全局变量的信息,当发现程序执行结果异常时,很难定位到是在哪个函数中出了差错。不少初学者觉得参数传递麻烦,将要处理的数据尽可能地定义为全局变量,这样,函数之间的接口简单了,但形成的是耦合性很强的结构。在C语言中,还可以通过静态局部变量,在同一个程序的两次调用之间共享数据,这也可以视为是一种外部耦合,只不过静态局部变量的作用域限于函数内部,其影响也只在函数内部,耦合程度比使全局变量也还是弱很多。由此,我们可以理解前述在使用全局变量、静态局部变量时提出的“用在合适的时候,不滥用”的原则。
      针对高内聚。内聚程度最高的是功能内聚,模块内所有元素的各个组成部分全部都为完成同一个功能而存在,共同完成一个单一的功能,模块已不可再分。这样的函数功能非常清晰、明确,一般出现在程序结构图的较低被调用的层次上。次之的是顺序内聚,一个函数中各个处理元素和同一个功能密切相关,通常前一个处理元素的输出是后一个处理元素的输入。对于这样的函数,如果不致于产生高耦合的话,可以分开两个函数实现。有的函数,其中的不同处理功能仅仅是由于都访问某一个公用数据而发生关联,这称为通信内聚信息内聚,内聚程度进一步下降。内聚程度再低的情况就不再一一列举,最差的偶然内聚中,一个函数内的各处理元素之间没有任何联系,只是偶然地被凑到一起。可以想像这样的模块东一榔头西一锤子,类似一个毫无凝聚力的团伙,对应的是低质量。总之,在解决问题划分函数时,要遵循“一个函数,一个功能”的原则,尽可能使模块达到功能内聚。
      要做到高内聚低耦合,重点是要在写代码之前花些时间做好设计。在下面的例子中,将讨论结合具体的问题,如何将以上的因素考虑进去。

    (二)示例篇

      本例受裘宗燕老师《从问题到程序——程序设计与C语言引论启发》。

    任务

    输出200以内的完全平方数(一个数如果是另一个整数的完全平方,那么我们就称这个数为完全平方数,也叫做平方数),要求每隔5个数据要输出一个换行。

    解决方案及点评

      对于这个简单任务,我们在一个main函数中完成了任务。程序如方案1:

    //方案1:内聚性较高的单模块实现方案
    #include <stdio.h>
    int main()
    {
        int m, num=0;
        for (m = 1; m * m <= 200; m++)
        {
            printf("%d ", m * m);
            num++;
            if (num%5==0)
                printf("\n");
        }
        return 0;
    }

      由于任务本身简单,将之在一个main函数中实现后,这个函数的内聚程度接近功能内聚,已经相当高了,就任务本身,不需再进行分解。为使读者能深入理解模块质量方面的技术,我们将试图将内聚程序再提高一些,然后考察耦合程度不同的各种解决方案。
      要提高上面解决方案中函数(仅main一个函数)的内聚程度,我们考察程度的功能“找出完全平方数并输出”——“找出完全平方数”和“输出”这本身就是两个功能,再细分输出时还有“要求5个数据在一行”的要求,这些功能的实现细节都在一个函数当中,可见是有余地再提高内聚程度的。在实现的应用中,几乎所有的处理都可以分解为“输入-计算-输出”的模式,优秀的解决方案往往至少要将这三个模块都独立出来,对于“计算”模块而言,其内部不再包括输入输出,专门接受输入的数据,计算完成后返回结果即可。当然,对于复杂的问题,在各个环节上可能还需要再做分解。
      下面,我们探讨将“找出完全平方数输出”和“每5个数据后换行”分开实现的方案。这样的分解有助于提高内聚性,与此同时,分解后的两个模块间的耦合程度,成为我们要关注的焦点。
      现在将“找出完全平方数并输出”的功能仍放在main函数中(独立成为单独的函数也可以,但不必要了),而“每5个数据后换行”的功能,设计一个名称为format的函数,它每调用一次就输出一个空格作为两个完全平方数间的分隔,而每调用到第5次时,输出的是一个换行。这两个模块之间,需要有一个“现在是第几次调用”的信息需要传递,不可能用耦合程度最松散的非直接耦合.我们考虑数据耦合,用简单形式参数传值,得到方案2。

    //方案2:一个耦合度低,但不能完成功能要求的解决方案
    #include <stdio.h>
    void format(int);
    int main()
    {
        int m, num=0;
        for (m = 1; m * m <= 200; m++)
        {
            printf("%d", m * m);
            format(num);
        }
        return 0;
    }
    void format(int n)
    {
        n++;
        if (n%5==0)
            printf("\n");
        else
            printf(" ");
        return;
    }

      在这个程序结构中,format与main函数的耦合程度为数据耦合。在main中定义了局部变量num,在一次都未输出时,置初值为0是合理的。在调用format时,将num传递来的表示第几次输出(第几个完全平方数)的形式参数n,n自增1,然后再控制输出空格或换行。
      然而分析和运行程序发现,“每隔5个数据输出一个换行”的功能并未实现。因为形式参数n在函数format内的改变对应的实在参数num占不同的内存空间,n++修改的结果,对num无任何的影响,导致了在下一次调用时,丢失了“输出的是第几个”的重要信息。
      一个补救的方法,是由format将变化后的n值作为返回值,再传回给main函数,得到如下方案3的程序:

    //方案3:利用了返回值使耦合度增大,但功能得以实现的方案
    #include <stdio.h>
    int format(int);
    int main()
    {
        int m, num=0;
        for (m = 1; m * m <= 200; m++)
        {
            printf("%d", m * m);
            num = format(num);
        }
        return 0;
    }
    int format(int n)
    {
        n++;
        if (n%5==0)
            printf("\n");
        else
            printf(" ");
        return n;
    }

      维持原函数返回值为void,而将参数改为传地址,得到下面的方案4。这个方案的耦合度更高一些,但功能还是能够实现的。

    //方案4:传地址实现功能的方案,耦合度更大
    #include <stdio.h>
    void format(int*);
    int main()
    {
        int m, num=0;
        for (m = 1; m * m <= 200; m++)
        {
            printf("%d", m * m);
            format(&num);
        }
        return 0;
    }
    void format(int *p)
    {
        (*p)++;
        if ((*p)%5==0)
            printf("\n");
        else
            printf(" ");
        return;
    }

      一定有人想到了用全局变量的解决方案。这样,可以将num定义为全局变量,num的生存周期不再依赖于函数调用,其值也能在函数的调用之间保持不变(只要其间没有另外给它赋值),从而可以完成传递信息的任务。这时,format因为无需参数传递,可以设计为无参函数,得到如下方案5的程序:

    //方案5:耦合度最高的全局变量方案
    #include <stdio.h>
    void format();
    int num=0;
    int main()
    {
        int m ;
        for (m = 1; m * m <= 200; m++)
        {
            printf("%d", m * m);
            format();
        }
        return 0;
    }
    void format()
    {
        num++;
        if (num%5==0)
            printf("\n");
        else
            printf(" ");
        return;
    }

      这是解决这个问题的耦合程度最高的一个方案。将num定义为外部变量,意味着如果还有其他函数,num是可以被任何函数修改的,当发 format 计数错误时,寻找错误困难,而修改后又可能会带来其他地方的错误。在这么一个短小的程序中,这种方案可能尚可接受,当程度的规模稍变大,可能带来的问题必须高度重视。因此,在实际应用中,强调全局变量要慎用(不是不用)。
      考虑到num是在format中应用的私用数据——只有format才关心这到底是第几个数据,main本来都不用关心的。这样,可以考虑将num定义为format中的局部静态变量,得到方案6的程序:

    //方案6:用静态局部变量,耦合度偏高但封装性最好的方案
    #include <stdio.h>
    void format();
    int main()
    {
        int m ;
        for (m = 1; m * m <= 200; m++)
        {
            printf("%d", m * m);
            format();
        }
        return 0;
    }
    void format()
    {
        static int num=0;
        num++;
        if (num%5==0)
            printf("\n");
        else
            printf(" ");
        return;
    }

      在这里,静态局部变量num的作用域是局部的,定义在函数体里,封装性在所有方案里是最好的,从而能保证信息的隐蔽性,避免其他函数无意的越权访问;不过,num的生存期是全局的,可以跨越函数的不同次调用,在两次调用间传递信息,耦合程度(自己和自己的耦合)要高一些,但使main函数和format函数的耦合达到了最理想的程度,既保证了功能的正确,又保证了局部数据的安全性,表现出静态局部变量的优势。
      综上所述,在解决一个问题时,存在着诸多的方案。方案1可以接受,但希望提高内聚性而做出改进;方案2用简单的参数传值方式实现耦合程度低,但很可惜不能完成功能;在其他方案中,对于这个问题,选择的优先顺序是:
      方案6、方案3 > 方案4 > 方案5
    建议读者回顾前面的内容,想一想这样排序的理由。
      在上述探讨各个方案的过程中,我们应该体会到在程序设计能力提高的过程中,不断地学习新的技术,懂得新的评判标准,这也就是一个不断拓宽眼蜀的过程。在稍后的练习中,不妨多想一些方案,也能够从专业的角度评判方案的优劣,最终做到的,就是出手就是最佳方案的专业水平。
      (全文完)

    展开全文
  • 软件工程-耦合与内聚

    千次阅读 2020-02-13 13:42:28
    根据耦合程度从高到低分类可分为数据耦合、控制耦合、特征耦合、公共环境耦合、内容耦合。 数据耦合是两个模块间通过参数传递信息。比如不同函数间通过值传递来传递变量信息,但因为是值传递形式,在调用被关联的...

    什么是耦合

    简单来说就是在编写程序不同模块间之间关联的程度度量。
    不同模块可以是不同函数,也可以是不同类。

    根据耦合程度从高到低分类可分为数据耦合、控制耦合、特征耦合、公共环境耦合、内容耦合。

    数据耦合是两个模块间通过参数传递信息。比如不同函数间通过值传递来传递变量信息,但因为是值传递形式,在调用被关联的函数后,变量就被释放了,这样就耦合程度较低,当程序出现错误时比较容易改错。

    特征耦合是指提供的数据多于需要的数据,这样多余的数据容易在关联的时候被修改。比如地址传递。

    举个例子

    
    void add1(int n){
    	n++;
    }
    void output(int n){
    	cout<<n<<endl;
    } 
    
    int add2(int n){
    	return n++;
    }
    void add3(int * n){
    	(*n)++;
    }
    void main(){
    	int n=0;
    	int m=0;
    	int p=0;
    	for(int i=0;i<10;i++){
    		add1(n);//main与add1函数是数据耦合
    		m=add2(m); 
    		p=add3(& p);
    	}
    	output(n);//与main与output控制耦合
    	output(m);
    }
    
    

    什么是聚合

    聚合是一个模块间内部各个元素间紧密程度的度量。内聚程度从高到低排序有功能内聚、顺序内聚、通信内聚、过程内聚、时间内聚、逻辑内聚、偶然内聚。

    如果一个函数只完成一个功能那么这个函数内部元素是功能内聚的。如上例中的add1,2,3函数。

    顺序内聚 如果一个模块内的处理元素同一个功能密切相关,且处理必须顺序执行则成为顺序内聚。(通常是一个处理元素的输出数据作为下一个处理元素的输入数据)

    偶然内聚 比如在编写一个函数时发现打印一个变量的语句反复用到,为了节省内存空间于是把这个元素间毫无关系的打印函数作为一个单独的模块,这就是偶然内聚。

    展开全文
  • 软件设计之高内聚低耦合

    千次阅读 2016-08-29 10:43:20
    原文出处:http://blog.csdn.net/nengyu/article/details/421416351. 低耦合(Low Coupling)“低耦合”这个词相信大家已经耳熟能详,我们在看spring的书籍、MVC的数据、设计模式的...,无处不提到“低耦合、高内聚”...

    原文出处:http://blog.csdn.net/nengyu/article/details/42141635

    1. 低耦合(Low Coupling)

    “低耦合”这个词相信大家已经耳熟能详,我们在看spring的书籍、MVC的数据、设计模式的书籍,无处不提到“低耦合、高内聚”,它已经成为软件设计质量的标准之一。那么什么是低耦合?耦合就是对某元素与其它元素之间的连接、感知和依赖的量度。这里所说的元素,即可以是功能、对象(类),也可以指系统、子系统、模块。假如一个元素A去连接元素B,或者通过自己的方法可以感知B,或者当B不存在的时候就不能正常工作,那么就说元素A与元素B耦合。耦合带来的问题是,当元素B发生变更或不存在时,都将影响元素A的正常工作,影响系统的可维护性和易变更性。同时元素A只能工作于元素B存在的环境中,这也降低了元素A的可复用性。正因为耦合的种种弊端,我们在软件设计的时候努力追求“低耦合”。低耦合就是要求在我们的软件系统中,某元素不要过度依赖于其它元素。请注意这里的“过度”二字。系统中低耦合不能过度,比如说我们设计一个类可以不与JDK耦合,这可能吗?除非你不是设计的Java程序。再比如我设计了一个类,它不与我的系统中的任何类发生耦合。如果有这样一个类,那么它必然是低内聚(关于内聚的问题我随后讨论)。耦合与内聚常常是一个矛盾的两个方面。最佳的方案就是寻找一个合适的中间点。

    哪些是耦合呢?

    • 元素B是元素A的属性,或者元素A引用了元素B的实例(这包括元素A调用的某个方法,其参数中包含元素B)。
    • 元素A调用了元素B的方法。
    • 元素A直接或间接成为元素B的子类。
    • 元素A是接口B的实现。

    幸运的是,目前已经有大量的框架帮助我们降低我们系统的耦合度。比如,使用struts我们可以应用MVC模型,使页面展现与业务逻辑分离,做到了页面展现与业务逻辑的低耦合。当我们的页面展现需要变更时,我们只需要修改我们的页面,而不影响我们的业务逻辑;同样,我们的业务逻辑需要变更的时候,我们只需要修改我们的java程序,与我们的页面无关。使用spring我们运用IoC(反向控制),降低了业务逻辑中各个类的相互依赖。假如类A因为需要功能F而调用类B,在通常的情况下类A需要引用类B,因而类A就依赖于类B了,也就是说当类B不存在的时候类A就无法使用了。使用了IoC,类A调用的仅仅是实现了功能F的接口的某个类,这个类可能是类B,也可能是另一个类C,由spring的配置文件来决定。这样,类A就不再依赖于类B了,耦合度降低,重用性提高了。使用hibernate则是使我们的业务逻辑与数据持久化分离,也就是与将数据存储到数据库的操作分离。我们在业务逻辑中只需要将数据放到值对象中,然后交给hibernate,或者从hibernate那里得到值对象。至于用Oracle、MySQL还是SQL Server,如何执行的操作,与我无关。

    但是,作为优秀的开发人员,仅仅依靠框架提供的降低软件耦合的方法是远远不够的。根据我的经验,以下一些问题我们应当引起注意:

    根据可能的变化设计软件

    我们采用职责驱动设计,设计中尽力做到“低耦合、高内聚”的一个非常重要的前提是,我们的软件是在不断变化的。如果没有变化我们当然就不用这么费劲了;但是如果有变化,我们希望通过以上的设计,使我们在适应或者更改这样的变化的时候,付出更小的代价。这里提供了一个非常重要的信息是,我们努力降低耦合的是那些可能发生变更的地方,因为降低耦合是有代价的,是以增加资源耗费和代码复杂度为代价的。如果系统中某些元素不太可能变更,或者降低耦合所付出的代价太大,我们当然就应当选择耦合。有一次我试图将我的表现层不依赖于struts,但发现这样的尝试代价太大而失去意义了。对于软件可能变更的部分,我们应当努力去降低耦合,这就给我们提出一个要求是,在软件设计的时候可以预判日后的变化。根据以往的经验我认为,一个软件的业务逻辑和采用的技术框架往往是容易变化的2个方面。客户需求变更是我们软件设计必须考虑的问题。在RUP的开发过程中,为什么需要将分析设计的过程分为分析模型和设计模型,愚以为,从分析模型到设计模型的过程实际上是系统从满足直接的客户需求到优化系统结构、适应可预见的客户需求变更的一个过程。这种客户需求的变更不仅仅指对一个客户需求的变更,更是指我们的软件从适应一个客户需求到适应更多客户需求的过程。另一个方面,现在技术变更之快,EJB、hibernate、spring、ajax,一个一个的技术像走马灯一样从我们脑海中滑过,我们真不知道明天我在用什么。在这样的情况下,适应变化就是我们最佳的选择。

    合理的职责划分

    合理的职责划分,让系统中的对象各司其职,不仅是提高内聚的要求,同时也可以有效地降低耦合。比如评审计划BUS、评审表BUS、评审报告BUS都需要通过评审计划DAO去查询一些评审计划的数据,如果它们都去直接调用评审计划DAO(如图A),则评审计划BUS、评审表BUS、评审报告BUS三个对象都与评审计划DAO耦合,评审计划DAO一旦变更将与这三个对象都有关。在这个实例中,实际上评审计划BUS是信息专家(关于信息专家模式我将在后面讨论),评审表BUS和评审报告BUS如果需要获得评审计划的数据,应当向评审计划BUS提出需求,由评审计划BUS提供数据(如图B)。经过这样的调整,系统的耦合度就降低了。

    使用接口而不是继承

    通过对耦合的分析,我们不难发现,继承就是一种耦合。如果子类A继承了父类B,不论是直接或间接的继承,子类A都必将依赖父类B。子类A必须使用在存在父类B的环境中,父类B不存在子类A就不能使用,这样将影响子类A的可移植性。一旦父类B发生任何变更,更改或去掉一个函数名,或者改变一个函数的参数,都将导致子类A不得不变更,甚至重写。假如父类B的子类数十上百个,甚至贯穿这个项目各个模块,这样的变更是灾难性的。这种情况最典型的例子是我们现在使用hibernate和spring设计DAO对象的方式,具体的描述参见我写的《如何在 struts + spring + hibernate的框架下构建低耦合高内聚的软件结构》一文。

    总之,“低耦合”给软件项目带来的优点是:易于变更、易于重用。

    2. 高内聚(High Cohesion)

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

    可读性

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

    复用性

    在软件开发中,最低等级的复用是代码拷贝,然后是函数的复用、对象的复用、组件的复用。软件开发中最懒的人是最聪明的人,他们总是想到复用。在代码编写的时候突然发现某个功能是曾经实现过的功能,直接把它拷贝过来就ok了。如果这段代码在同一个对象中,那么就提出来写一个函数到处调用就行了。如果不是在同一个对象中呢,就将其抽象成一个对象到处调用吧。如果不在一个项目中呢,那就做成组件给各个项目引用吧。代码复用也使我们的代码在复用的过程中不断精化、不断健壮、提高代码质量。代码的复用的确给我们的开发带来了不少便利,但是一段代码能否在各个需要的地方都能复用呢?这给我们的软件开发质量提出了新的要求:好的代码可以复用,不好的则不行。软件中的一个对象如果能保证能完成自己职能范围内的各项任务,同时又不去理会与自己职能无关的其它任务,那么它就能够保证功能的相对独立性,也就可以脱离自己所处的环境而复用到其它环境中,这是一个具有内聚性的对象。

    可维护性和易变更性

    在前面《如何在struts+spring+hibernate的框架下构建低耦合高内聚的软件》中我提到,我们现在的软件是在不断变更的,这种变更不仅来自于我们的客户,更来自于我们的市场。如果我们的软件通过变更能及时适应我们的市场需求,我们就可以在市场竞争中获胜。如何能及时变更以适应我们的市场呢,就是通过调整软件的结构,使我们每次的变更付出的代价最小,耗费的人力最小,这种变更才最快最经济。高内聚的软件,每个系统、模块、类的任务都高度相关,就使每一次的变更涉及的范围缩小到最小。比如评审表发生了变更,只会与评审表对象有关,我们不会去更改其它的对象。如果我们能做到这一点,我们的系统当然是可维护性好、易变更性好的系统。

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

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

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

    综上所述,“高内聚”给软件项目带来的优点是:可读性强、易维护和变更、支持低耦合、移植和重用性强。

    • 耦合、内聚的评估标准是强度,耦合越弱越好,内聚越强越好;
    • 所谓过度指的是由于错误理解导致的效果相反的设计;
    • 耦合指的模块之间的关系,最弱的耦合设计是通过一个主控模块来协调n个模块之间的运作。还是举一个我举过的例子:客户要求在界面上增加一个字段,你的项目要修改几个地方呢?如果你只要修改项目文档,那么你的开发构架就是最低强度的耦合,而这种设计 成熟的开发团队都已经做到了,他们使用开发工具通过项目模型驱动数据库和各层次的代码,而不是直接修改那些代码;
    • 内聚指的是模块内部的功能,最强的内聚就是功能单一到不能拆分,也就是原子化,
    • 所以强内聚和弱耦合是相辅相成的,一个良好的设计是由若干个强内聚模块以弱耦合的方式组装起来的

    高内聚、低耦合讲的是程序单位协作的问题, 你可以这样理解,一个企业的管理, 最理想的情况就是各个部门各司其职,井然有序,互不干涉, 但是需要沟通交流的时候呢, 各个部门都可以找到接口人专门负责部门沟通以及对外沟通。

    在软件里呢, 就是说各个模块要智能明确, 一个功能尽量由一个模块实现, 同样,一个模块最好只实行一个功能。这个是所谓的“内聚”; 模块与模块之间、系统与系统之间的交互,是不可避免的,但是我们要尽量减少由于交互引起的单个模块无法独立使用或者无法移植的情况发生, 尽可能多的单独提供接口用于对外操作, 这个就是所谓的“低耦合”。

    但是实际的设计开发过程中,总会发生这样那样的问题与情况,真正做到高内聚、低耦合是很难的,很多时候未必一定要这样,更多的时候“最适合”的才是最好的,不过,理解思想,审时度势地使用,融会贯通,灵活运用,才是设计的王道。

    展开全文
  • 软件工程中的常见耦合

    千次阅读 2017-11-14 15:58:41
    耦合性(Coupling),也叫耦合度,是对模块间关联程度的度量。...软件设计中通常用耦合度和内聚度作为衡量模块独立程度的标准。划分模块的一个准则就是高内聚低耦合。 一般模块之间可能的连接方式
  • 模块独立性指每个模块只完成系统要求的独立子功能,并且与其他模块的联系最少且接口简单,两个定性的度量标准――耦合性和内聚性。  耦合性也称块间联系。指软件系统结构中各模块间相互联系紧密程度的一种度量。...
  • 软件工程作业答案3

    2020-07-19 23:30:57
    5-1为每种模块的耦合举一个具体例子 5-2为每种模块的内聚举一个具体例子 5-3用面向数据流的方法设计下列系统的软件结构
  • 软件工程导论期末复习 1.2软件工程 软件工程是指导计算机软件开发与维护的一门工程学科(实用学科) **软件工程的本质特性 **(1)软件工程关注于大型工程的构造 (2)软件工程的中心课题是控制复杂性 (3)软件经常...
  • 软件工程知识点复习总结

    万次阅读 多人点赞 2018-01-07 23:23:07
    软件工程
  • 面对对象原则:高内聚、低耦合

    千次阅读 2016-06-24 21:18:27
    这是软件工程中的概念,是判断设计好坏的标准,主要是面向OO的设计,主要是看类的内聚性是否高,偶合度是否低.每一个类完成特定的独立的功能,这个就是高内聚。耦合就是类之间的互相调用关系,如果耦合很强,互相...
  • 软件工程基础知识

    万次阅读 2018-09-04 23:02:41
    软件工程知识点总结 有以下知识点(考试内容,当然不止这些)   1. 软件工程的定义 2. 软件生存周期 3. 软件过程模型 4. 需求分析的定义、获取 5. 常见的软件体系结构(B/S 、C/S 、软件总线中间件) 6. ...
  • 程序的耦合和解耦

    2019-08-02 17:43:36
    什么是程序的耦合 耦合性(Couping),也叫耦合度,是对程序间关联程度的度量,耦合的强弱取决于模块间接口的复杂性,调用模块的方式以及...耦合性存在于哥哥领域,而非软件设计中独有的,但是我们只讨论软件工程中的耦合. ...
  • 软件工程知识点总结

    2019-07-23 16:29:45
    软件工程知识点总结 有以下知识点(考试内容,当然不止这些) 1. 软件工程的定义 2. 软件生存周期 3. 软件过程模型 4. 需求分析的定义、获取 5. 常见的软件体系结构(B/S 、C/S 、软件总线中间件) 6. SOA ...
  • 软件工程导论》复习知识点总结

    万次阅读 多人点赞 2019-01-11 21:56:27
    软件工程导论 第一章 软件工程学概述 1. 软件工程的7条基本原理: 用分阶段的生命周期计划严格管理;坚持进行阶段评审;实行严格的产品控制;采用现代程序设计技术;结果应能清楚的审查;开发小组的人应该少而...
  • 软件工程: 选择题(25题,每题1分), 填空题(20分,每空2分), 简答题(5题,每题5分), 综合题(3题,共30分) 2.知识点 知识点: 1、软件设计对模块间的耦合与模块的内聚有何原则。 详见50124总体...
  • 起因:模块独立性指每个模块只完成系统要求的独立子功能,并且与其他模块的联系最少且接口简单,两个定性的度量标准――耦合性和内聚性。  耦合性也称块间联系。指软件系统结构中各模块间相互联系紧密程度的一...
  • 工程代码结构(附带几个demo) 嵌入式软件架构设计 模块化 & 分层设计 其实我们说到最后,好的代码,我们分层,做模块,无非就是实现一个高内聚和低耦合。 举个简单的例子,将某个模块代码直接删除之后,将上层...
  • 软件工程自学笔记一(基础篇)

    千次阅读 2019-03-14 13:41:46
    软件工程三要素软件工程目标之间的关系软件工程的原则原则一:抽象原则二:信息隐蔽原则三:模块化原则四:局部化原则五:确定性原则六:一致性原则七:完备性原则八:可验证性软件工程的本质特征软件工程的基本...
  • 软件设计之——“高内聚低耦合耦合度 一、什么是耦合软件设计中通常用耦合度和内聚度作为衡量模块独立程度的标准。划分摸块的一个准则就是高内聚低耦合耦合度(Coupling)是对模块间关联程度的度量。耦合的...
  • 山东大学软件工程复习要点及答案

    千次阅读 2019-12-21 15:12:34
    找到这篇文章的人一定被软件工程考试搞得头秃吧。 这篇文章将会让你不再那么头秃~ 文章内容仅供参考,如有错误,请指正。 Chapter01 SE的定义、目的、方法及作用? 定义:软件工程即用系统科学的工程性...
1 2 3 4 5 ... 20
收藏数 21,302
精华内容 8,520
关键字:

例子 耦合 软件工程