精华内容
下载资源
问答
  • 低耦合 高内聚

    千次阅读 2021-01-14 13:24:28
    一 什么是低耦合耦合度(Coupling)是对模块间关联程度的度量。耦合的强弱取决与模块间接口的复杂性、调用模块的方式以及通过界面传送数据的多少。 模块间的耦合度是指模块之间的依赖关系,包括控制关系、... 内聚和耦...

    一 什么是低耦合

    耦合度(Coupling)是对模块间关联程度的度量。耦合的强弱取决与模块间接口的复杂性、调用模块的方式以及通过界面传送数据的多少。 模块间的耦合度是指模块之间的依赖关系,包括控制关系、调用关系、数据传递关系。模块间联系越多,其耦合性越强,同时表明其独立性越差。降低模块间的耦合度能减少模块间的影响,防止对某一模块修改所引起的“牵一发动全身”的水波效应,保证系统设计顺利进行。 内聚和耦合密切相关,同其它模块存在强耦合关系的模块常意味这弱内聚,强内聚常意味着弱耦合。

    耦合度就是某模块(类)与其它模块(类)之间的关联、感知和依赖的程度,是衡量代码独立性的一个指标,也是软件工程设计

    及编码质量评价的一个标准。耦合的强度依赖于以下几个因素:

    (1)一个模块对另一个模块的调用;

    (2)一个模块向另一个模块传递的数据量;

    (3)一个模块施加到另一个模块的控制的多少;

    (4)模块之间接口的复杂程度。

    下面这些情况会造成类A、B之间的耦合:

    a.       A是B的属性

    b.       A调用B的实例的方法

    c.       A的方法中引用了B,例如B是A方法的返回值或参数。

    d.       A是B的子类,或者A实现了B

    耦合按从强到弱的顺序可分为以下几种类型:

    a)非直接耦合:两模块间没有直接关系,之间的联系完全是通过主模块的控制和调用来实现的

    b)数据耦合:一个模块访问另一模块,彼此间通过简单数据参数来交换输入、输出信息。这里的简单数据参数不同于控制参数、公共数据结构或外部变量。

    c)标记耦合:如一组模块通过参数表传递记录信息,就是标记耦合。这个记录是某一数据结构的子结构,不是简单变量。

    d)控制耦合:一个模块通过传递开关、标志、名字等控制信息,明显的控制选择另一模块的功能

    e)外部耦合:一组模块都访问同一全局简单变量而不是同一全局数据结构,而且不是通过参数传递该全局变量的信息

    f)公共耦合:一组模块都访问同一个公共数

    据环境。该公共数据环境可以是全局数据结构、共享的通信区、内存的公共覆盖区等。

    g)内容耦合:一个模块直接修改另一个模块的数据,或直接转入另一个模块

    内聚度是指内部各元素之间联系的紧密程度,模块的内聚种类通常可分为7种,按其内聚度从低

    到高的次序依此为:偶然内聚、逻辑内聚、瞬时内聚、过程内聚、通信内聚、顺序内聚、功能内聚。

    二  为什么要低耦合

    耦合度很高的情况下,维护代码时修改一个地方会牵连到很多地方

    三  如何实现低耦合

    1、少使用类的继承,多用接口隐藏实现的细节。因为继承本身就是耦合,一个类的实现必须依赖于另外一个类,如果基类不存在了就不能工作了。 java面向对象编程引入接口除了支持多态外, 隐藏实现细节也是其中一个目的。

    2、模块的功能化分尽可能的单一,道理也很简单,功能单一的模块供其它模块调用的机会就少。(其实这是高内聚的一种说法,高内聚低耦合一般同时出现,为了限制篇幅,我们将在以后的版期中讨论)。

    3、遵循一个定义只在一个地方出现。

    4、少使用全局变量。

    5、类属性和方法的声明少用public,多用private关键字,

    6、多用设计模式,比如采用MVC的设计模式就可以降低界面与业务逻辑的耦合度。

    7、尽量不用“硬编码”的方式写程序,同时也尽量避免直接用SQL语句操作数据库。

    8、最后当然就是避免直接操作或调用其它模块或类(内容耦合);如果模块间必须存在耦合,原则上尽量使用数据耦合,少用控制耦合,

    限制公共耦合的范围,避免使用内容耦合。

    +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

    四 什么是高内聚

    故名思议,表示内部间聚集、关联的长度,那么高内聚就是指要高度的聚集和关联。高内聚:类与类之间的关系而定,高,意思是他们之间的关系要简单,明了,不要有很强的关系,不然,运行起来就会出问题。一个类的运行影响到其他的类。

    五 高内聚的好处

    由于高内聚具备鲁棒性,可靠性,可重用性,可读性等优点,模块设计推荐采用高内聚。

    六  如何实现高内聚

    每一个类完成特定的独立的功能,这个就是高内聚。

    展开全文
  • 如果元素具有高度相关的职责,除了这些职责内的任务,没有其它过多的工作,那么该元素就具有高内聚性,反之则为低内聚性。高内聚要求软件系统中的各个元素具有较的协作性,因为在我们在完成软件需求中的一个功能,...

    高内聚(High Cohesion)

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

    1.可读性

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

    2.复用性

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

    3.可维护性和易变更性

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

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

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

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

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

    低耦合(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的框架下构建低耦合高内聚的软件结构》一文。

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

    展开全文
  • 下面要给大家分享的是一个高内聚低耦合例子,那么编程应该如何实现高内聚低耦合呢?一起来看看下面的实例吧!案例:在一个学校里面,有着老师若干名,依次编号。有学生若干名,依次编号。现在的话,是要求要打印出学校...

    下面要给大家分享的是一个高内聚低耦合例子,那么编程应该如何实现高内聚低耦合呢?一起来看看下面的实例吧!

    案例:

    在一个学校里面,有着老师若干名,依次编号。

    有学生若干名,依次编号。

    现在的话,是要求要打印出学校里面所有老师和学生的ID。import java.util.ArrayList;

    import java.util.List;

    class Teacher

    {

    privateString id;

    publicvoidsetId(String id)

    {

    this.id = id;

    }

    publicString getId()

    {

    return id;

    }

    }

    class Student

    {

    private String id;

    public void setId(String id)

    {

    this.id = id;

    }

    public String getId()

    {

    return id;

    }

    }

    class StudentManage

    {

    publicList  getAllStudent()

    {

    List  list = newArrayList  ();

    for (int i = 0; i 

    {

    Student student = new Student();

    student.setId("学生学号是" + i);

    list.add(student);

    }

    return list;

    }

    public void printAllStudent()

    {

    List  list1 = this.getAllStudent();

    for (Student s: list1)

    {

    System.out.println(s.getId());

    }

    }

    }

    class TeacherManage

    {

    publicList  getAllTeacher()

    {

    List  list = newArrayList  ();

    for (inti = 0; i 

    {

    Teacher teacher = new Teacher();

    teacher.setId("老师编号" + i);

    list.add(teacher);

    }

    return list;

    }

    publicvoidprintAllTeacher()

    {

    List  list2 = this.getAllTeacher();

    for (Teacher t: list2)

    {

    System.out.println(t.getId());

    }

    }

    }

    public classClient

    {

    publicstaticvoidmain(String[] args)

    {

    TeacherManagetm = newTeacherManage();

    tm.printAllTeacher();

    StudentManagesm = newStudentManage();

    sm.printAllStudent();

    }

    }

    低耦合高内聚原则本来就是为了降低了类之间的耦合。

    因为每一个类减少了不必要的依赖,所以,的确能够降低耦合关系。

    可是凡是都是要有度的,虽然说能够避免和非直接的类通信,可是,要通信,就一定要通过一个中介来发生关系,利用这个方法能够做到结构清晰,高内聚低耦合。

    一个小的高内聚低耦合例子就给大家分享到这里了,你还想了解更多的java实例吗?请继续关注奇Q工具网来进行了解吧!

    推荐阅读:

    展开全文
  • 总结 上面我们已经讲解了低耦合高内聚的二个原则,通过这2个原则我们知道,满足这2个原则是衡量一个架构设计好坏的一个参考标准。下面我们将来讲解通过 功能分离的方式来满足上面的2个原则。 五、如何满足设计...

    本文转自:http://www.cnblogs.com/hegezhou_hot/archive/2010/09/18/1830306.html

    一、上章回顾

    在上篇中我们讲解了几类UML2.0语言新推出的建模图形,总体来说通过这些图形能更详细的将某类信息表达出来。在这里我们简单回顾上篇讲解的内容。

    上图中已经简单介绍了上章讲述的内容,具体内容请看:系统架构师-基础到企业应用架构-系统建模[下篇]。

    二、摘要

    本章将主要的简单介绍在系统架构中的设计模式及相应规范准则。并结合相应的代码来说明如何遵循系统架构中的一些基本的设计规范及准则。而我们将在本文介

    绍几类常用的设计规范,我们先来看看结构化设计的二个基本原则:

    当然既然提出了基本的准则,那么我们如何来满足准则呢,并且能更好的设计呢?我们可以通过如下手段来达到这样的要求:

     当然图中演示了功能分离的策略,通过把需求按照不同的功能详细的划分开来,每个功能都是独立

    的,当然我们这里也可以成为是关注点。下面我们将针对这些原则进行详细的讲解。

    三、本章内容

    1、上章回顾。

    2、摘要。

    3、本章内容。

    4、设计规范及原则。

    5、如何满足设计要求。

    6、本章总结。

    7、系列进度。

    8、下篇预告。

    四、设计规范及准则。

    1、高内聚

    首先我们来看看内聚的含义:软件含义上的内聚其实是从化学中的分子的内聚演变过来的,化学中的分子间的作用力,作用力强则表现为内聚程度高。在软件中内

    聚程度的高低,标识着软件设计的好坏。

    我们在进行架构设计时的内聚高低是指,设计某个模块或者关注点时,模块或关注点内部的一系列相关功能的相关程度的高低。

    例如:下单模块:

     一般情况下,下单模块都会有如下的信息,订单的信息,产品的信息及谁下的单(买家信息)。这是基

    本的,那么我们设计的时候就要把相关的功能内聚到一起。当然这是从大功能(下单管理)上来说,当然这些模块还可以再细化分成产品、订单、会员等子模块。

    例如我们在设计数据库操作辅助类提供的方法有:

     通过这样的方式,那么这个组件只负责数据库操作。这样带来的好处也是显而易见的。高内

    聚提供了更好的可维护性和可复用性。而低内聚的模块则表名模块直接的依赖程度高,那么一旦修改了该模块依赖的对象则无法使用该模块,必须也进行相应的修改才

    可以继续使用。

    低内聚的模块设计的坏处有:首先模块的功能不单一,模块的职责不明确,比较松散,更有甚者是完成不相关的功能。这样的设计往往是不可取的。可以通过重

    构来完善。

    下面我们来说下高内聚的简单解释:什么样的模块算是高内聚,并且能够在系统中很好的使用。

    那么我们在设计的过程中如何去完成高内聚呢?

    以上基本上讲述了高内聚的好处,并且阐述了如何实现高内聚的步骤和原则。下面我们来说说可能高内聚带来的坏处。

    高内聚有时候也不是说所有的情况都采用这样的原则,当然高内聚还是要适度的,下面来举例说明:例如内聚性要求强的话就像Windows32中系统提供的

    API,里面的函数太多了,都放在一个Dll中,那么每个函数完成一个功能。这样强大的功能,会比较复杂,所以并不是完全的高内聚越高越好,还是要看实际的需要。

    当然维护起来也不是特别的方便。

    2、低耦合

    首先我们来看看低耦合的定义:低耦合是用来度量模块与模块直接的依赖关系。耦合当然也可以这样简单的理解,我想懂电脑的应该都知道,CPU与主板之间的

    关系,CPU如果是特殊的CPU必须使用特殊的主板来支持,那么如果说这个CPU不唯一依赖唯一主板,那么就认为这个CPU与主板的关系是低耦合的关系。

    下面我们来举例说明低耦合的设计与高耦合的设计:

     这是一个简单的低耦合的设计,电器与插座之间是低耦合的关系,就算我替换了不同的插座,电器依

    然可以正常的工作。因此简单的描述如下,就是A模块与B模块存在依赖关系,那么当B发生改变时,A模块仍然可以正常工作,那么就认为A与B是低耦合的。

    1、笔记本接音响可以正常的使用。

    2、笔记本接专配耳机正常的使用。

    对应一般的音响来说,笔记本是通用的,音响和笔记本直接的关系是低耦合的,但是笔记本和耳机却是高耦合的,只有专配的耳机才能和笔记本互联使用,而不

    是通用的,所以说笔记本和专配耳机存在着较强的依赖关系。当然最简单的方式就是笔记本提供统一的耳机接口,可以满足一般性的需求。

    下面我们将来分析如何构建低耦合的设计。

    总结

    上面我们已经讲解了低耦合和高内聚的二个原则,通过这2个原则我们知道,满足这2个原则是衡量一个架构设计好坏的一个参考标准。下面我们将来讲解通过

    功能分离的方式来满足上面的2个原则。

    五、如何满足设计要求

    1、如何按功能进行模块化的分离。

    我们在将一个系统进行功能划分时,我们一般如下来进行:

    首先、我们先把功能职责划分成独立的单元。

    例如现在有个B2C系统,那么我们按照B2C的需求,如下分析:

     我们这里简单的分析下B2C应该具有的功能模块,当然这些模块的划分中,有些模

    块还可以继续的分离,当然我这里只是实例分析出来。

    2、对分离出来的模块化进行抽象,例如我们以支付为例。

     这里通过支付接口向外提供服务。那么外界模块不关心支付系统模块的变化,只需要调用接口

    即可,如果具体的支付方式,比如支付宝的方式发生改变,在调用支付服务的模块中也不需要做任何的修改就可以正常的提供服务。显然这样的方式是不错的实现方

    式。

    通常情况下我们在系统分离式只是以接口的方式提供服务,供其他的模块进行使用。在模块内部有大量的信息是不要向外部暴露的,所以模块在设计时访问域的定

    义就要划分好,防止因为访问域的定义而对模块的信息造成破坏。

    下面我们来看下功能分离在不同的设计理念下都是什么样的表现:

    上面只是实体性的分析了功能分离的好处及应用的广度,当然我们在后续会结合实例来讲解如何来实现这样的软件设计模式。当然这只是软件的架构设计,那么如

    果细化到具体的实现呢?我们如何去设计每个功能点呢?这就是下章我们要讲解的内容了,那么本文先列出二种常见的方式。

    下篇我们将针对设计原则中的实现方式,进行详细的剖析与具体实现进行举例讲解,希望大家多提意见。

    六、本章总结。

    本章中主要简单的讲述了软件设计的二个基本的规范与原则:

    1、高内聚:描述了模块内部的一系列功能的相关程度,对于功能之间相关度不高或者根本没有相关性的功能包含在模块中的做法是不可取的。

    2、低耦合:描述了模块直接的依赖、感知程度,耦合的衡量标准是从低到高,一般来说耦合度越低越好。

    当然有些特殊情况下,可能这二个原则也有矛盾的地方,当然我们还是要根据项目的实际需要及情况进行抉择,当然这二个原则是为了设计提供更好的扩展性、

    可读性、可维护性、极高的可复用性,所以要求我们在设计时尽量去满足这二个基本原则。而帮我去达到这二个准则的途径就是通过功能分离及细化来实现这样的准

    则。下一篇我们将深入的分析与举例来说明实现这二个原则的各种规范及准则。

    七、系列进度

    前篇

    7、系统架构师-基础到企业应用架构-系统设计规范与原则[下篇]

    8、系统架构师-基础到企业应用架构-设计模式[上篇]

    9、系统架构师-基础到企业应用架构-设计模式[中篇]

    10、系统架构师-基础到企业应用架构-设计模式[下篇]

    中篇

    11、系统架构师-基础到企业应用架构-企业应用架构

    12、系统架构师-基础到企业应用架构-分层[上篇]

    13、系统架构师-基础到企业应用架构-分层[中篇]

    14、系统架构师-基础到企业应用架构-分层[下篇]

    15、系统架构师-基础到企业应用架构-表现层

    16、系统架构师-基础到企业应用架构-服务层

    17、系统架构师-基础到企业应用架构-业务逻辑层

    18、系统架构师-基础到企业应用架构-数据访问层

    19、系统架构师-基础到企业应用架构-组件服务

    20、系统架构师-基础到企业应用架构-安全机制

    后篇

    21、单机应用、客户端/服务器、多服务、企业数据总线全解析

    22、系统架构师-基础到企业应用架构-单机应用(实例及demo)

    23、系统架构师-基础到企业应用架构-客户端/服务器(实例及demo)

    24、系统架构师-基础到企业应用架构-多服务(实例及demo)

    25、系统架构师-基础到企业应用架构-企业数据总线(实例及demo)

    26、系统架构师-基础到企业应用架构-性能优化(架构瓶颈)

    27、系统架构师-基础到企业应用架构-完整的架构方案实例[上篇]

    28、系统架构师-基础到企业应用架构-完整的架构方案实例[中篇]

    29、系统架构师-基础到企业应用架构-完整的架构方案实例[下篇]

    30、系统架构师-基础到企业应用架构-总结及后续

    八、下篇预告。

    下一篇将会已我们将深入的讲解功能分离的设计准则及实现方式,如何在设计中使用设计模式来构建满足高内聚、低耦合的功能模块等等。将通过实例化的方式对

    每种原则及实现模式进行分析和举例。如果大家有好的意见和建议可以及时反馈,谢谢您的宝贵意见。

    后语

    希望看完本章的朋友可以从本篇中学到相应的软件设计规范,懂的人可以温习下相应设计准则,本篇希望能够抛砖引玉,希望大家能够多提出宝贵意见。由于是本

    人平时工作中的理解与总结,不足之处再所难免,还请大家批评指出!如果您有什么意见或建议,请多多提出!大家的支持就是我的最大动力!

    展开全文
  • 高内聚低耦合的理解

    2021-03-15 15:21:48
    以下转自百度百科内聚耦合耦合:是对模块间关联程度的度量。耦合的强弱取决与模块间接口的复杂性、调用模块的方式以及通过界面传送数据的多少。 模块间的耦合度是指模块之间的依赖关系,包括控制关系、调用关系、...
  • 低耦合耦合就是元素与元素之间的连接,感知和依赖量度。这里说的元素即是功能,对象,系统,子系统。模块。 例如:现在有方法A和方法B 我们在A元素去调用B元素,当B元素有问题或者不存在的时候,A元素就不能...
  • 点击上方“Java知音”,选择“置顶公众号”技术文章第一时间...耦合主要描述模块之间的关系, 内聚主要描述模块内部。 模块的粒度可大可小, 可以是函数, 类, 功能块等等。耦合模块之间存在依赖, 导致改动可能...
  • 耦合主要描述模块之间的关系, 内聚主要描述模块内部. 模块的粒度可大可小,可以是函数, 类, 功能块等等.耦合模块之间存在依赖, 导致改动可能会互相影响, 关系越紧密, 耦合越强, 模块独立性越差.比如...
  • 如果元素具有高度相关的职责,除了这些职责内的任务,没有其它过多的工作,那么该元素就具有高内聚性,反之则为低内聚性。高内聚要求软件系统中的各个元素具有较的协作性,因为在我们在完成软件需求中的一个功能,...
  • 划分模块的一个准则是高内聚低耦合。从模块粒度来看,内聚:尽可能类的每个成员方法只完成一件事(最大限度的聚合); 低耦合:减少类内部,一个成员方法调用另一个成员方法。从类角度来看, 高内聚低耦合:减少类...
  • 接口体现的是一种规范和实现分离的设计哲学,充分利用接口可以极大的降低程序中各个模块之间的耦合,提高系统的可维护性以及可扩展性。因此,很多的软件架构设计理念都倡导“面向接口编程”而不是面向实现类编程,...
  • 耦合主要描述模块之间的关系, 内聚主要描述模块内部。模块的粒度可大可小, 可以是函数, 类, 功能块等等。耦合模块之间存在依赖, 导致改动可能会互相影响, 关系越紧密, 耦合越强, 模块独立性越差。比如模块A...
  • 大家好,我是晓宇,不知道大家有没有听过软件设计中的低耦合高内聚的两个原则。具体是什么意思呢?在一个项目中:每个模块之间相联系越紧密,则耦合性越;这样你改动其中一个模块,其他模块也需...
  • 技术人员不断变换,代码规范层次不齐无论是在大厂还是在小团队,项目早期以快、业务实现为要求,比如并发、数据仓库、风控控制都不会接入。而互联网团队的开发人员、产品经理一般在职时间1-2年会正常生命周期,在...
  • 维基上对其定义为:一种软件开发技术- 面向服务的体系结构(SOA)架构样式的一种变体,将应用程序构造为一组松散耦合的服务。在微服务体系结构中,服务是细粒度的,协议是轻量级的。 微服务(或微服务架构)是一种...
  • 高内聚低耦合

    2021-07-09 09:41:58
    美国的计算机科学家,图灵奖得主 Alan Kay 说过一句话: 当你自己在编程的时候,如果写的非常顺手,这时候就要考虑是不是这种砌墙的感觉,是不是缺少逻辑,比如有很多 switch case1 case2 case3.....高内聚耦...
  • 我们常听一些厉害的程序员说过高内聚低耦合,小伙伴们知道它们是什么意思吗?下面听小编为你解析一下。什么是低耦合?官方的说,耦合就是元素与元素之间的连接、感知与依赖量度。元素代表什么?这里的元素代指各种...
  • 总所周知,实际软件开发中要实现高内聚低耦合的设计原则。c语言和c++不同,c语言面向过程、c++面向对象。真正的项目中。要对业务升级。原来的业务函数须要保留,要保证老的功能继续维持,不能直接删除。这时候...
  • 自从我们接触到编程开始,就知道了软件设计的总的原则,低耦合高内聚,无论是面向对象或者面向过程,耦合度尽量,才能提高代码的复用率。但是编程怎么编程低耦合呢?无论逻辑怎么复杂,对于依赖的类来说,都尽量...
  • 高内聚低耦合详解

    2021-02-25 17:43:59
    内聚关注模块内部的元素结合程度,耦合关注模块之间的依赖程度。 内聚性: 又称块内联系。指模块的功能强度的度量,即一个模块内部各个元素彼此结合的紧密程度的度量。若一个模块内各元素(语名之间、程序段之间)...
  • 大家好,我是小麦,不知道大家有没有听过软件设计中的低耦合高内聚的两个原则。具体是什么意思呢?在一个项目中:每个模块之间相联系越紧密,则耦合性越;这样你改动其中一个模块,其他模块也需...
  • 高内聚低耦合,是软件工程中的概念,是判断软件设计好坏的标准,主要用于程序的面向对象的设计,主要看类的内聚性是否耦合度是否低。目的是使程序模块的可重用性、移植性大大增强。通常程序结构中各模块的内聚...
  • 高内聚低耦合,是 软件工程 中的概念,是判断软件设计好坏的标准,主要用于程序的 面向对象 的设计,主要看类的内聚性是否耦合度 是否低。 目的是使程序模块的可重用性、移植性大大增强。 通常程序结构中各模块...
  • 设计模式追求的目的就是“高内聚低耦合”,在实际编程中运用设计模式能够使我们工程代码更规范、重用性更,同时也能保证代码的可靠性、提高开发效率。 一、概述 面向对象编程有七大原则,即经常提到的设计模式...
  • 高内聚低耦合是一种程序设计的思想,内聚的本质也就抽象和封装,目的是为了代码结构清晰,减少代码量。低耦合的目的是为了不同服务之间不同的业务代码不混用,降低了整体宕机的风险。 当然,如果说抽象和封装的...
  • 软件项目实训及课程设计指导——如何实现程序类设计的高内聚低耦合的系统设计目标(上篇)1、前言为了能够设计和实现一个内聚、低耦合的软件应用系统,软件应用系统的设计和开发人员不仅要有灵活的系统体系架构设计...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 73,157
精华内容 29,262
关键字:

低耦合高内聚