这是软件工程中的概念,是判断设计好坏的标准,主要是面向OO的设计,主要是看类的内聚性是否高,偶合度是否低。
一个程序有50个函数,这个程序执行得非常好;然而一旦你修改其中一个函数,其他49个函数都需要做修改,这就是高耦合的后果。编写概要设计的时候设计类或者模块自然要考虑到“高内聚,低耦合”。
在程序的各各模块中,尽量让每个模块独立,相关的处理尽量在单个模块中完成,(该干嘛干吗去!) 优点:能提降低各模块的之间的联系,减少“牵一发而动全身”的几率,提高开发效率,降低升级维护成本,也便于进行单元测试,提高软件质量。在开发设计的时候考虑当前模块或者类如何更便捷的进行单元测试,考虑的过程也就是降耦的过程。
低耦合(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那里得到值对象。至于用Oracle、MySQL还是SQL Server,如何执行的操作,与我无关。
但是,作为优秀的开发人员,仅仅依靠框架提供的降低软件耦合的方法是远远不够的。根据我的经验,以下一些问题我们应当引起注意:
1) 根据可能的变化设计软件
我们采用职责驱动设计,设计中尽力做到“低耦合、高内聚”的一个非常重要的前提是,我们的软件是在不断变化的。如果没有变化我们当然就不用这么费劲了;但是如果有变化,我们希望通过以上的设计,使我们在适应或者更改这样的变化的时候,付出更小的代价。这里提供了一个非常重要的信息是,我们努力降低耦合的是那些可能发生变更的地方,因为降低耦合是有代价的,是以增加资源耗费和代码复杂度为代价的。如果系统中某些元素不太可能变更,或者降低耦合所付出的代价太大,我们当然就应当选择耦合。有一次我试图将我的表现层不依赖于struts,但发现这样的尝试代价太大而失去意义了。对于软件可能变更的部分,我们应当努力去降低耦合,这就给我们提出一个要求是,在软件设计的时候可以预判日后的变化。根据以往的经验我认为,一个软件的业务逻辑和采用的技术框架往往是容易变化的2个方面。客户需求变更是我们软件设计必须考虑的问题。在RUP的开发过程中,为什么需要将分析设计的过程分为分析模型和设计模型,愚以为,从分析模型到设计模型的过程实际上是系统从满足直接的客户需求到优化系统结构、适应可预见的客户需求变更的一个过程。这种客户需求的变更不仅仅指对一个客户需求的变更,更是指我们的软件从适应一个客户需求到适应更多客户需求的过程。另一个方面,现在技术变更之快,EJB、hibernate、spring、ajax,一个一个的技术像走马灯一样从我们脑海中滑过,我们真不知道明天我在用什么。在这样的情况下,适应变化就是我们最佳的选择。
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的子类数十上百个,甚至贯穿这个项目各个模块,这样的变更是灾难性的。这种情况最典型的例子是我们现在使用hibernate和spring设计DAO对象的方式,具体的描述参见我写的《如何在 struts + spring + hibernate的框架下构建低耦合高内聚的软件结构》一文。
总之,“低耦合”给软件项目带来的优点是:易于变更、易于重用。
耦合:一个软件结构内不同模块之间互连程度的度量(耦合性也叫块间联系。指软件系统结构中各模块间相互联系紧密程度的一种度量。模块之间联系越紧密,其耦合性就越强,模块的独立性则越差,模块间耦合的高低取决于模块间接口的复杂性,调用的方式以及传递的信息。) 对于低耦合,粗浅的理解是:一个完整的系统,模块与模块之间,尽可能的使其独立存在。
高内聚(High Cohesion)
高内聚是另一个普遍用来评判软件设计质量的标准。内聚,更为专业的说法叫功能内聚,是对软件系统中元素职责相关性和集中度的度量。如果元素具有高度相关的职责,除了这些职责内的任务,没有其它过多的工作,那么该元素就具有高内聚性,反之则为低内聚性。高内聚要求软件系统中的各个元素具有较高的协作性,因为在我们在完成软件需求中的一个功能,可能需要做各种事情,但是具有高内聚性的一个元素,只完成它职责内的事情,而把那些不在它职责内的事情拿去请求别人来完成。这就好像,如果我是一个项目经理,我的职责是监控和协调我的项目各个阶段的工作。当我的项目进入需求分析阶段,我会请求需求分析员来完成;当我的项目进入开发阶段,我会请求软件开发人员来完成;当我的项目需要测试的时候,我会请求测试人员。。。。。。如果我参与了开发,我就不是一个高内聚的元素,因为开发不是我的职责。我们的项目为什么要高内聚呢?我觉得可以从可读性、复用性、可维护性和易变更性四个方面来理解。
1.可读性
一个人写文章、讲事情,条理清晰才能易于理解,这同样发生在读写软件代码上。如果一堆代码写得一团乱麻,东一个跳转西一个调用,读它的人会感觉非常头疼。这种事情也许一直在写程序的你我都曾经有过经历。如果一段程序条理非常清晰,每个类通过名称或说明都能清楚明白它的意义,类的每个属性、函数也都是易于理解的它所应当完成的任务和行为,这段程序的可读性必然提高。在软件产业越来越密集,软件产业中开发人员协作越来越紧密、分工越来越细的今天,软件可读性的要求相信也越来越为人们所重视。
2.复用性
在软件开发中,最低等级的复用是代码拷贝,然后是函数的复用、对象的复用、组件的复用。软件开发中最懒的人是最聪明的人,他们总是想到复用。在代码编写的时候突然发现某个功能是曾经实现过的功能,直接把它拷贝过来就ok了。如果这段代码在同一个对象中,那么就提出来写一个函数到处调用就行了。如果不是在同一个对象中呢,就将其抽象成一个对象到处调用吧。如果不在一个项目中呢,那就做成组件给各个项目引用吧。代码复用也使我们的代码在复用的过程中不断精化、不断健壮、提高代码质量。代码的复用的确给我们的开发带来了不少便利,但是一段代码能否在各个需要的地方都能复用呢?这给我们的软件开发质量提出了新的要求:好的代码可以复用,不好的则不行。软件中的一个对象如果能保证能完成自己职能范围内的各项任务,同时又不去理会与自己职能无关的其它任务,那么它就能够保证功能的相对独立性,也就可以脱离自己所处的环境而复用到其它环境中,这是一个具有内聚性的对象。
3.可维护性和易变更性
在前面《如何在struts+spring+hibernate的框架下构建低耦合高内聚的软件》中我提到,我们现在的软件是在不断变更的,这种变更不仅来自于我们的客户,更来自于我们的市场。如果我们的软件通过变更能及时适应我们的市场需求,我们就可以在市场竞争中获胜。如何能及时变更以适应我们的市场呢,就是通过调整软件的结构,使我们每次的变更付出的代价最小,耗费的人力最小,这种变更才最快最经济。高内聚的软件,每个系统、模块、类的任务都高度相关,就使每一次的变更涉及的范围缩小到最小。比如评审表发生了变更,只会与评审表对象有关,我们不会去更改其它的对象。如果我们能做到这一点,我们的系统当然是可维护性好、易变更性好的系统。
那么,我们如何做到高内聚呢?就拿前面我提到的评审项目举例。我现在要为“评审表”对象编写一段填写并保存评审表的代码。评审表对象的职责是更新和查询评审表的数据,但是在显示一个要填写的评审表的时候,我需要显示该评审计划的名称、该评审计划有哪些评审对象需要评审。现在我如何编写显示一个要填写的评审表的代码?我在评审表对象的这个相应的函数中编写一段查询评审计划和评审对象的代码吗?假如你这样做了,你的代码就不是高内聚的,因为查询评审计划和评审对象的数据不是它的职责。正确的方法应当去请求“评审计划”对象和“评审对象”对象来完成这些工作,而“评审表”对象只是获取其结果。
另外,如果一个对象要完成一个虽然在自己职责范围内,但过程非常复杂的任务时,也应当将该任务分解成数个功能相对独立的子函数来完成。我曾经看见一个朋友写的数百行的一个函数,让人读起来非常费劲。同时这样的函数中一些相对独立的代码,本可以复用到其它代码中,也变成了不可能。所以我给大家的建议是,不要写太长的函数,超过一百行就可以考虑将一些功能分解出去。
与“低耦合”一样,高内聚也不是一个绝对,而是一个相对的指标,应当适当而不能过度。正如我们在现实生活中,如果在一个十来人的小公司,每个人的分工可能会粗一些,所分配的职责会广一些杂一些,因为其总体的任务少;而如果在一个一两百人的大公司,每个人的分工会细一些,所分配的任务会更加专一些,因为总体任务多,更需要专业化的分工来提高效率。软件开发也是一样,如果“评审计划”对象完成的业务功能少,并且不复杂,它完全可以代理它的子表“评审对象”和“评审者”的管理。但是“评审计划”对象需要完成的“对评审计划表的管理”这个基本职责包含的业务功能繁多或者复杂,它就应当将“对评审对象表的管理”交给“评审对象”对象,将“对评审者表的管理”交给“评审者”对象。同样,高内聚的可维护性好、易变更性好只能是一个相对的指标。如果一个变更的确是大范围的变更,你永远不可能通过内聚就不进行大范围的变更了。同时内聚也是要付出代价的,所以你也不必要去为了一个不太可能的变更去进行过度设计,应当掌握一个度。过度的内聚必将增加系统中元素之间的依赖,提高耦合度。所以“高内聚”与“低耦合”是矛盾的,必须权衡利弊,综合地去处理。在李洋等人翻译的《UML和模式应用》中,将内聚和耦合翻译为软件工程中的阴与阳,是中国人对内聚和耦合的最佳解释。
综上所述,“高内聚”给软件项目带来的优点是:可读性强、易维护和变更、支持低耦合、移植和重用性强。
内聚和耦合,包含了横向和纵向的关系。功能内聚和数据耦合,是我们需要达成的目标。横向的内聚和耦合,通常体现在系统的各个模块、类之间的关系,而纵向的耦合,体现在系统的各个层次之间的关系。
对于我在编码中的困惑,我是这样想的,用面向对象的思想去考虑一个类的封装。
一个方法,如何封装,拿到现实生活中来看,看这种能力(方法)是否是属于这类事物(类)的本能。
如果是,就封装在这个类里。
如果不是,则考虑封装在其它类里。
如果这种能力,很多事物都具有,则一定要封装在这类事物的总类里。
如果这种能力,很多事物都会经常用到,则可以封装成一个总类的静态方法。
关于耦合内聚的概念
这些是软件工程中的知识,我上网查过,总结着几位大虾的评论,关于耦合的概念应该是这样的:
1,对象之间的耦合度就是对象之间的依赖性.指导使用和维护对象的主要问题是对象之间的多重依赖性.对象之间的耦合性越高.维护成本越高.因此对象的设计应使类和构件之间的耦合最小.
2,耦合性是程序结构中各个模块之间相互关联的度量.它取决于各个模块之间的接口的复杂程度,调用模块的方式一级哪些信息通过接口,一般模块之间可能的连接方式有七种,耦合性由低到高分别是:非直接耦合,数据耦合,标记耦合,控制耦合,外部耦合,公共耦合,内容耦合.
一个软件是由多个子程序组装而成,而一个程序由多个模块(方法)构成.
耦合是指各个外部程序(子程序)之间的关系紧密度
而内聚就是指程序内的各个模块之间的关系紧密度
所以说,为什么要高内聚,模块之间的关系越紧密,出错就越少!低耦合就是说,子程序之间的关系越复杂,就会产生出更多的意想不到的错误!会给以后的维护工作带来很多麻烦。
转自:http://blog.csdn.net/XYTsoft2001/article/details/332658
转自:http://wenwen.soso.com/z/q27093689.htm
转自:http://200830740306.iteye.com/blog/615445
转自:http://hi.baidu.com/lanxigang/blog/item/d2c45960e01f01d78cb10dd1.html
分享到:
相关推荐
软件系统的设计思想和原则、设计 方法、系统架构及体系结构、设计模式、运行平台、 开发工具等方面进行综合考虑和合理取舍。
耦合度就是某模块(类)与其它模块(类)之间的关联、感知和依赖的程度,是衡量代码独立性的一个指标,也是软件工程设计及编码质量评价的一个标准
1.3.1 高内聚、低耦合 1.3.2 面向抽象编程 1.3.3 多用组合少用继承 1.3.4 “开-闭”原则 1.4 设计模式概述 1.4.1 什么是设计模式 1.4.2 为什么需要设计模式 1.4.3 如何正确应用设计模式 1.5 设计模式的分类 ...
是对于《软件设计与规范》所学知识与技能的一次综合训练,在此次实验中,我们遵循软件设计规范的规则,使用EntityFramework框架,Autofac依赖注入Ioc容器,工厂模式,单例模式,遵循高内聚,低耦合的设计原则,...
C)低内聚高耦合 B)高内聚低耦合 D)高内聚高耦合 (6)下列选项中不属于结构化程序设计原则的是( )。 A)可封装 B)自顶向下 C)模块化 (7)软件详细设计产生的图如下: begin Y N D)逐步求精
这是一个可拓展的对内封闭的...在软件、程序设计的时候,追求的目标是达到封装变化、降低耦合,来实现高内聚低耦合。开放封闭原则正是对这一目标的最直接体现,而其他的设计原则,很多时候也是为实现这一目标服务的。
按照设计模式中“高内聚、低耦合”的原则,设计出一种标图系统的整体结构,并以Prototype, Template Method, Observer, Command, Composite和Singleton六种具体模式为例,详细阐述了它们在系统功能实现过程中的应用...
根据面向对象设计中高内聚低耦合的设计原则,将紧耦合的类目划入同一个类图,而耦合度低的类目间实现分离.为了确保生成的类图大小合适,拆分方法对每个类图的大小进行限定,将每个类图的大小限定在预先定义的合理区间内...
在进行概要设计时,模块的独立性是一个有关质量的重要技术性指标,可以使用模块的内聚、耦合这两个定性参数对模块独立性进行度量。 2.软件详细设计 设计工作的第二步是详细设计,它以概要设计为依据,用于确定软件...
第3章 软件系统设计 3 ...3.6.2.2 高内聚 38 3.6.2.3 低耦合 39 3.6.2 模块设计的规程与模板 40 3.7 数据结构与算法设计理念 42 3.8 应用示例 43 3.8.1 成功的示例 43 3.8.2 半成半败的示例 44 3.9 小结 44
应⽤架构设计有⼏个核⼼的原则: 开放-封闭原则:即对扩展开放,对修改封闭 ⾼内聚低耦合原则:尽量将功能相关的内容组合在⼀起,封装后对外提供接⼝。 封装变化原则:越是可能发⽣变化的地⽅越要进⾏处理和封装,将...
高内聚与松耦合原则 数据库应用系统功能设计与实施全文共2页,当前为第2页。数据库应用系统功能设计与实施全文共2页,当前为第2页。4.3.3 数据访问层概要设计:主要任务就是针对DBAS的数据处理需求设计用于操作...
大学生招聘网本着软件开发的设计...从框架上分的三层:界面层UI、业务逻辑层BLL、数据访问层DAL,区分层次的目的即为了“高内聚低耦合”的思想,在软件系统架构设计中,分层式结构是最常见的,也是最重要的一种结构。
模块化是软件设计的关键原则之一。 为了使软件系统模块化,应该将其组织为内部高度一致的模块,同时尽可能与其他模块独立。 在本文中,我们探讨了软件包级别(即,面向对象(OO)系统中软件功能分解的最基本级别之一...
模块高内聚 C.模块低耦合 D.模块独立性 5.软件测试的目的是( B )。 A.评价软件的质量 B.发现软件的错误C.找出软件的所有错误 D.证明软件是正确的 6.在设计测试用例时,( A )是用得最多的一种黑盒测试方法。 ...
面向对象系统的分析和设计实际上追求的就是两点,一是高内聚(Cohesion),而是低耦合(Coupling)。这也是我们软件设计所准求的,因此无论是OO中的封装、继承、多态,还是我们的设计模式的原则和实例都是在为了这两...
1.什么是设计模式? 2.设计模式是指在软件开发中,经过验证的,用于解决在特定环境下、重复出现的、特定问题的解决方案。 3.说出你所知道的设计模式?...11.为什么类要高内聚低耦合? 12.目的是使程序模块
1、计算机软件结构设计中划分模块时,尽量做到高内聚、低耦合,保持模块相对独立性,并以些原则优化初始的软件结构。( A ) A、正确 B、错误 2、当一台客户机需要另一台主机的IP地址时,一般它首先查询自己所在的DNS...
1.5 内聚(功能内聚) 2.设计的任务 3.程序的一般结构 4.软件体系结构(变换型、事务型) 三、软件测试 1.测试的目的、原则和对象 2.测试用例设计 2.1 白盒测试(语句覆盖、判定覆盖) 2.2 黑盒测试...
本着高内聚、低耦合的原则,我归纳出了校园智慧节水管理系统的具体功能模块,具体包括:设备管理模块、智慧节水模块、用户管理模块、异常上报模块、公告信息模块、用户管理模块、节水论坛模块、节水信息管理模块、...