高内聚,低耦合
无耦合基和耦合基
无耦合基和耦合基无耦合基和耦合基是软件工程中常用的概念。
本文将分别介绍无耦合基和耦合基的概念、特点以及在软件设计中的应用。
一、无耦合基无耦合基是指在软件设计中，模块之间没有直接依赖关系或紧密联系的基础。
它的特点是各个模块之间相互独立，可以独立进行开发、测试和维护。
无耦合基的设计原则是高内聚、低耦合。
高内聚是指模块内部的功能高度相关，模块内部的各个元素紧密地结合在一起，实现单一责任。
低耦合是指模块之间的依赖关系尽可能地降低，模块之间的通信通过接口进行，减少模块之间的直接关联。
在软件设计中，无耦合基的应用可以提高代码的可维护性和可扩展性。
当一个模块需要修改时，只需要关注自身的实现，而不需要担心对其他模块的影响。
同时，无耦合基也方便进行单元测试，可以独立测试每个模块的功能。
二、耦合基耦合基是指在软件设计中，模块之间存在直接依赖关系或紧密联系的基础。
它的特点是各个模块之间相互关联，修改一个模块可能会影响其他相关的模块。
耦合基的设计原则是低内聚、高耦合。
低内聚是指模块内部的功能不够相关，模块内部的各个元素之间关联性较弱。
高耦合是指模块之间的依赖关系较强，一个模块的修改可能会导致其他相关模块的修改。
在软件设计中，耦合基的应用会增加代码的复杂性和维护难度。
当一个模块需要修改时，可能需要考虑对其他相关模块的影响，导致修改过程复杂而困难。
同时，由于模块之间的紧密联系，也会增加代码的耦合度，导致系统的可扩展性较差。
在软件设计中，无耦合基和耦合基都有各自的应用场景。
无耦合基适用于需要独立开发、测试和维护的模块，例如独立的功能模块或库。
无耦合基可以使各个模块的功能独立，易于理解和调试。
同时，无耦合基也便于代码的重用，可以将独立的模块直接引入其他项目中使用。
耦合基适用于需要紧密协作的模块，例如一个大型系统中的各个子系统或模块。
耦合基可以使各个模块之间的通信更加直接和高效，提高系统的整体性能。
同时，耦合基也便于模块之间的数据共享和交互，可以更好地满足系统的需求。
简述模块的几种耦合类型,以及模块耦合设计原则
简述模块的几种耦合类型,以及模块耦合设计原则
模块的几种耦合类型包括紧密耦合、控制耦合、内容耦合、公共耦合和无耦合。
紧密耦合指模块之间存在大量相互依赖的情况，例如一个模块的修改可能会导致其他模块的变化；控制耦合指一个模块对另一个模块产生控制或影响，导致模块间的耦合；内容耦合指模块之间共享数据或信息，导致耦合性增加；公共耦合指多个模块共同依赖一个公共模块，当公共模块发生变化时，所有依赖的模块都需要进行修改；无耦合指模块之间没有任何依赖关系，模块间相互独立。
模块耦合设计原则包括高内聚、低耦合、单一职责原则和开闭原则。
高内聚指一个模块内部要求模块内部元素都有相关性，相互协作实现模块功能，减少模块之间的耦合性；低耦合指模块之间尽量减少直接相互依赖，通过接口或抽象类进行解耦；单一职责原则指一个模块只负责单一功能，避免一个模块承担多个功能导致模块之间相互影响；开闭原则指模块应该对扩展开放，对修改关闭，避免因修改一个模块而影响其他模块。
这些原则有助于设计出高可维护、可扩展的模块化系统。
- 1 -。
高内聚低耦合 高扇入底扇出
1：高扇入
扇入？扇入是什么东东？我以前还真不知道，仔细一看原来就是指被其它类或方法引用。
那高扇入也就是说你这个类/方法...被很多其它类引用了。
也就是利用率很高了。
按照我的想法如果段代码我连写了三次,我就会把它单独作为一个方法或类
2: 低扇出
扇出自然就是引用其它类或方法了.按Bob大叔的说法，扇出越高，类就越不稳定，因为任何一个引用对象出问题了，这个类也就会出问题。
另外McConnell 说了：引用超过约七个就算高扇出了. 对其它类的引用过多，导致该类不稳定（取决所有引用类）
3:高内聚
内聚就是一个模块内各个元素彼此结合的紧密程度，高内聚就是一个模块内各个元素彼此结合的紧密程度高。
所谓高内聚是指一个软件模块是由相关性很强的代码组成，只负责一项任务，也就是常说的单一责任原则。
4:松耦合
一个软件结构内不同模块之间互连程度的度量(耦合性也叫块间联系。
指软件系统结构中个模块间相互联系紧密程度的一种度量。
模块之间联系越紧密，其耦合性就越强，模块的独立性则越差，模块间耦合的高低取决于模块间接口的复杂性，调用的方式以及传递的信息。
功能对等四个原则
功能对等四个原则功能对等是指软件系统中各个组件之间平等地提供功能，任何一个组件都可以不依赖其他组件的存在独自完成其功能的能力。
它是一种良好的系统设计原则，有助于提高系统的可扩展性、可维护性和可测试性。
在实际开发中，应该遵循以下四个功能对等的原则。
第一个原则是高内聚。
高内聚是指一个组件应该只关注完成自己的功能，而不涉及其他组件的内部逻辑。
每个组件都应该有清晰的界限，只完成自己的功能，这样可以更好地保持组件的独立性和复用性。
高内聚的组件可以更容易地被理解、维护和测试。
第二个原则是低耦合。
低耦合是指组件之间的依赖应该尽量减少，每个组件应该是独立的，不依赖其他组件的具体实现。
组件之间的通信应该通过明确定义的接口进行，而不是直接依赖其他组件的内部实现。
低耦合的组件可以更容易地进行模块化设计和单元测试。
第三个原则是单一职责。
单一职责是指一个组件应该只有一个明确的责任，而不应该承担太多的功能。
每个组件应该尽量做到功能的清晰和独立，避免出现一个组件承担太多功能的情况。
单一职责的组件可以更好地进行功能复用和维护。
第四个原则是可替换性。
可替换性是指任何一个组件都可以被替换成另一个具有相同功能的组件，而不影响系统的其他部分。
每个组件应该有明确的接口定义，其他组件只需要依赖接口就可以和它进行交互。
可替换性的组件可以更好地适应系统的需求变化和技术选择的改变。
功能对等的四个原则有助于提高系统的可扩展性、可维护性和可测试性。
高内聚和低耦合可以提高系统的模块化程度，每个组件都有明确的边界和责任，更容易被理解和修改。
单一职责可以使系统的功能更加清晰和独立，避免组件之间功能的混淆和耦合。
可替换性可以使系统更容易适应需求的变化和技术的进步，减少对具体实现的依赖。
在实际开发中，我们应该努力遵循功能对等的原则，在系统设计和开发过程中注重组件的独立性和界限，避免组件之间的过度依赖和功能的冲突。
同时，我们还应该注重接口的定义和设计，提供清晰明确的接口，使得组件之间的交互更加规范和可替换。
软件系统设计原则
软件系统设计原则1.单一职责原则：一个类应该只负责一项职责，在类的设计中应该尽量保持高内聚、低耦合，不将多个职责耦合在一个类中。
这样可以提高类的可复用性、可测试性和可维护性。
2.开放封闭原则：软件系统中的类、模块和函数应该对扩展开放，对修改封闭。
当需求发生变化时，应该通过新增代码来实现新功能，而不是修改已有的代码。
这样可以避免修改已有代码带来的风险，保证系统的稳定性和扩展性。
3.里氏替换原则：任何父类出现的地方，都可以用其子类替换。
子类应该继承父类的行为，并且不应该改变父类所期望的结果。
这样可以确保在使用多态时不会带来意外的结果，降低了系统的耦合性。
4.依赖倒置原则：高层模块不应该依赖于低层模块，二者都应该依赖于抽象。
具体的类尽量依赖于接口或抽象类，而不是依赖于其他具体类。
这样可以降低类之间的耦合性，提高系统的扩展性和维护性。
5.接口分离原则：使用多个具体的接口比使用一个总的接口要好。
一个类应该只依赖于其需要使用的接口，而不应该依赖于其他不需要的接口。
这样可以降低类之间的耦合性，提高代码的可复用性和可维护性。
6.迪米特原则：一个类应该尽量减少对其他类的依赖，即一个类不应该知道太多其他类的细节，只应该与其直接的朋友进行交流。
这样可以减少类之间的依赖关系，降低系统的耦合性，使得系统的模块更加独立和易于修改。
7.高内聚低耦合原则：模块内部的元素应该紧密相关，而模块之间的关系应该相对较弱。
高内聚指的是模块内的元素一起工作，完成一个明确的任务；低耦合指的是模块之间的相互依赖尽可能地少。
这样可以提高系统的可维护性、可测试性和可复用性。
8.组合优于继承原则：在设计时优先考虑使用组合关系，而不是继承关系。
组合关系可以灵活地组合对象，减少类之间的耦合性，提高系统的灵活性和扩展性。
继承关系容易造成类之间的紧耦合，且继承是一种静态的关系，无法动态修改。
总之，软件系统设计原则是指导软件架构设计和开发的一些基本准则，可以帮助开发人员提高软件系统的质量、可重用性和可维护性。
流程分层解耦的三个基本原则
流程分层解耦的三个基本原则下载温馨提示:该文档是我店铺精心编制而成，希望大家下载以后，能够帮助大家解决实际的问题。
文档下载后可定制随意修改，请根据实际需要进行相应的调整和使用，谢谢!并且，本店铺为大家提供各种各样类型的实用资料，如教育随笔、日记赏析、句子摘抄、古诗大全、经典美文、话题作文、工作总结、词语解析、文案摘录、其他资料等等，如想了解不同资料格式和写法，敬请关注!Download tips: This document is carefully compiled by theeditor. I hope that after you download them,they can help yousolve practical problems. The document can be customized andmodified after downloading,please adjust and use it according toactual needs, thank you!In addition, our shop provides you with various types ofpractical materials,such as educational essays, diaryappreciation,sentence excerpts,ancient poems,classic articles,topic composition,work summary,word parsing,copy excerpts,other materials and so on,want to know different data formats andwriting methods,please pay attention!1. 单一职责原则：每个流程应该只负责一项特定的任务或功能，避免将多个不同的任务混合在一个流程中。
简述系统设计的原则
简述系统设计的原则系统设计是指按照一定目标和要求，构建出能够满足特定需求的复杂系统。
在系统设计的过程中，需要遵循一些基本原则，以确保系统的可靠性、稳定性、可维护性和扩展性。
本文将从以下几个方面介绍系统设计的原则。
一、模块化模块化是指将系统划分为若干个独立的模块，每个模块都具有一定的功能，且模块之间的相互依赖程度尽量降低。
这样，当需要对系统进行修改或升级时，只需要对特定的模块进行修改，而不必对整个系统进行重构。
同时，模块化还可以提高系统的可维护性和可扩展性，降低系统开发的复杂度。
二、高内聚低耦合内聚是指模块内部包含的元素之间的联系程度，高内聚意味着模块内部的元素紧密相关，低内聚则意味着模块内部的元素关联度较低。
耦合是指模块之间的相互依赖程度，高耦合意味着模块之间的依赖关系很强，低耦合则意味着模块之间的依赖关系较弱。
高内聚低耦合的设计原则可以降低系统内部的复杂度，提高系统的可维护性和可扩展性，同时也可以减少系统因外部变化而导致的影响。
三、单一职责单一职责是指每个模块只承担一个特定的责任或功能。
这样，当需要对某个功能进行修改或升级时，只需修改对应的模块，而不会影响到其他模块。
同时，单一职责还可以提高代码的可读性和可维护性，使系统更易于理解和维护。
四、开放封闭原则开放封闭原则是指模块应该对扩展开放，对修改封闭。
也就是说，当需要对系统进行升级或扩展时，应该通过添加新的模块或组件来完成，而不是修改已有的模块或组件。
这样，可以保护已有的模块或组件不受到意外的影响，同时也可以提高系统的可扩展性和可维护性。
五、分层结构分层结构是指将系统划分为若干个层次，每个层次都具有一定的功能和职责，并且层与层之间的通信只能通过接口进行。
这样，可以降低系统内部的复杂度，提高系统的可维护性和可扩展性，同时也可以保护系统的安全性。
六、面向对象设计面向对象设计是指将系统中的所有元素都看作对象，每个对象都具有一定的属性和方法，并且对象之间可以相互调用和交互。
系统模块划分：如何合理划分系统模块,实现模块化、高内聚、低耦合的设计
系统模块划分：如何合理划分系统模块，实现模块化、高内聚、低耦合的设计介绍系统模块划分是软件开发中非常重要的一环，它决定了软件系统的设计结构和组织方式。
合理划分系统模块可以带来诸多好处，如增强代码的可读性和可维护性，提高开发效率，降低系统复杂度等。
本文将探讨如何进行合理的系统模块划分，以实现模块化、高内聚、低耦合的设计。
什么是系统模块划分系统模块划分是将大型软件系统划分为若干相互独立、可复用的模块的过程。
每个模块都有特定的功能和责任，通过模块之间的协作和交互来完成系统的各项任务。
模块的划分需要考虑系统的需求、功能和架构，以及具体的开发环境和资源限制。
模块化的优势模块化设计具有许多优势。
首先，模块化能够提高代码的可读性和可维护性。
模块化将系统划分为多个小模块，每个模块负责特定的功能。
这样一来，每个模块的代码将更加简洁明了，易于理解和维护。
在修改系统时，我们只需要关注特定的模块，而不用担心影响其他模块的功能。
其次，模块化可以提高开发效率。
模块化将大型系统划分为多个小模块，可以将开发任务分配给多个开发人员或团队并行处理。
这种并行开发的方式可以节省开发时间，并提高开发效率。
模块化还可以促进代码的复用，减少重复开发的工作量，提高开发的重复利用率。
系统模块划分的原则为了实现模块化、高内聚、低耦合的设计，我们需要遵循一些原则进行系统模块的划分。
下面是一些常用的系统模块划分原则。
单一职责原则单一职责原则是指每个模块应该只负责完成一个单一的功能或任务。
一个模块的功能应该尽量单一而独立，避免一个模块承担过多的责任。
这样可以保证每个模块的代码简洁清晰，易于理解和维护。
例如，在一个电商系统中，可以将购物车模块、订单模块和用户模块等划分为独立的模块，每个模块负责自己的功能。
高内聚原则高内聚原则是指一个模块内部的各个组成部分之间应该紧密相关，协同工作。
一个模块内的各个组件应该具有高内聚性，即功能相关，相互依赖，共同完成一个任务。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
对高内聚，低耦合的理解内聚：一个模块内各个元素彼此结合的紧密程度耦合：一个软件结构内不同模块之间互连程度的度量(耦合性也叫块间联系。
指软件系统结构中个模块间相互联系紧密程度的一种度量。
模块之间联系越紧密，其耦合性就越强，模块的独立性则越差，模块间耦合的高低取决于模块间接口的复杂性，调用的方式以及传递的信息。
)最近编码的时候，总是在犹豫是把某个方法封装在一个类里，还是单独的封装成一个类。
这让我突然想起内聚耦合这两个名词。
我们一直追求着，高内聚，低耦合。
对于低耦合，粗浅的理解是：一个完整的系统，模块与模块之间，尽可能的使其独立存在。
也就是说，让每个模块，尽可能的独立完成某个特定的子功能。
模块与模块之间的接口，尽量的少而简单。
如果某两个模块间的关系比较复杂的话，最好首先考虑进一步的模块划分。
这样有利于修改和组合。
对于低耦合，我粗浅的理解是：在一个模块内，让每个元素之间都尽可能的紧密相连。
也就是充分利用每一个元素的功能，各施所能，以最终实现某个功能。
如果某个元素与该模块的关系比较疏松的话，可能该模块的结构还不够完善，或者是该元素是多余的。
内聚和耦合，包含了横向和纵向的关系。
功能内聚和数据耦合，是我们需要达成的目标。
横向的内聚和耦合，通常体现在系统的各个模块、类之间的关系，而纵向的耦合，体现在系统的各个层次之间的关系。
对于我在编码中的困惑，我是这样想的，用面向对象的思想去考虑一个类的封装。
一个方法，如何封装，拿到现实生活中来看，看这种能力（方法）是否是属于这类事物（类）的本能。
如果是，就封装在这个类里。
如果不是，则考虑封装在其它类里。
如果这种能力，很多事物都具有，则一定要封装在这类事物的总类里。
如果这种能力，很多事物都会经常用到，则可以封装成一个总类的静态方法。
关于耦合内聚的概念这些是软件工程中的知识,我上网查过,总结着几位大虾的评论,关于耦合的概念应该是这样的:1,对象之间的耦合度就是对象之间的依赖性.指导使用和维护对象的主要问题是对象之间的多重依赖性.对象之间的耦合性越高.维护成本越高.因此对象的设计应使类和构件之间的耦合最小.2,耦合性是程序结构中各个模块之间相互关联的度量.它取决于各个模块之间的接口的复杂程度,调用模块的方式一级哪些信息通过接口,一般模块之间可能的连接方式有七种,耦合性由低到高分别是:非直接耦合,数据耦合,标记耦合,控制耦合,外部耦合,公共耦合,内容耦合.一个软件是由多个子程序组装而成,而一个程序由多个模块(方法)构成.耦合是指各个外部程序(子程序)之间的关系紧密度而内聚就是指程序内的各个模块之间的关系紧密度所以说,为什么要高内聚,模块之间的关系越紧密,出错就越少!低耦合就是说,子程序之间的关系越复杂,就会产生出更多的意想不到的错误!会给以后的维护工作带来很多麻烦一个优秀软件开发人员的必修课：高内聚高内聚Java 软件工程软件模式一个重要的模式：高内聚。
2. 高内聚（High Cohesion）高内聚是另一个普遍用来评判软件设计质量的标准。
内聚，更为专业的说法叫功能内聚，是对软件系统中元素职责相关性和集中度的度量。
如果元素具有高度相关的职责，除了这些职责内的任务，没有其它过多的工作，那么该元素就具有高内聚性，反之则为低内聚性。
高内聚要求软件系统中的各个元素具有较高的协作性，因为在我们在完成软件需求中的一个功能，可能需要做各种事情，但是具有高内聚性的一个元素，只完成它职责内的事情，而把那些不在它职责内的事情拿去请求别人来完成。
这就好像，如果我是一个项目经理，我的职责是监控和协调我的项目各个阶段的工作。
当我的项目进入需求分析阶段，我会请求需求分析员来完成；当我的项目进入开发阶段，我会请求软件开发人员来完成；当我的项目需要测试的时候，我会请求测试人员。
如果我参与了开发，我就不是一个高内聚的元素，因为开发不是我的职责。
我们的项目为什么要高内聚呢？我觉得可以从可读性、复用性、可维护性和易变更性四个方面来理解。
1．可读性一个人写文章、讲事情，条理清晰才能易于理解，这同样发生在读写软件代码上。
如果一堆代码写得一团乱麻，东一个跳转西一个调用，读它的人会感觉非常头疼。
这种事情也许一直在写程序的你我都曾经有过经历。
如果一段程序条理非常清晰，每个类通过名称或说明都能清楚明白它的意义，类的每个属性、函数也都是易于理解的它所应当完成的任务和行为，这段程序的可读性必然提高。
在软件产业越来越密集，软件产业中开发人员协作越来越紧密、分工越来越细的今天，软件可读性的要求相信也越来越为人们所重视。
2．复用性在软件开发中，最低等级的复用是代码拷贝，然后是函数的复用、对象的复用、组件的复用。
软件开发中最懒的人是最聪明的人，他们总是想到复用。
在代码编写的时候突然发现某个功能是曾经实现过的功能，直接把它拷贝过来就ok了。
如果这段代码在同一个对象中，那么就提出来写一个函数到处调用就行了。
如果不是在同一个对象中呢，就将其抽象成一个对象到处调用吧。
如果不在一个项目中呢，那就做成组件给各个项目引用吧。
代码复用也使我们的代码在复用的过程中不断精化、不断健壮、提高代码质量。
代码的复用的确给我们的开发带来了不少便利，但是一段代码能否在各个需要的地方都能复用呢？这给我们的软件开发质量提出了新的要求：好的代码可以复用，不好的则不行。
软件中的一个对象如果能保证能完成自己职能范围内的各项任务，同时又不去理会与自己职能无关的其它任务，那么它就能够保证功能的相对独立性，也就可以脱离自己所处的环境而复用到其它环境中，这是一个具有内聚性的对象。
3．可维护性和易变更性在前面《如何在struts+spring+hibernate的框架下构建低耦合高内聚的软件》中我提到，我们现在的软件是在不断变更的，这种变更不仅来自于我们的客户，更来自于我们的市场。
如果我们的软件通过变更能及时适应我们的市场需求，我们就可以在市场竞争中获胜。
如何能及时变更以适应我们的市场呢，就是通过调整软件的结构，使我们每次的变更付出的代价最小，耗费的人力最小，这种变更才最快最经济。
高内聚的软件，每个系统、模块、类的任务都高度相关，就使每一次的变更涉及的范围缩小到最小。
比如评审表发生了变更，只会与评审表对象有关，我们不会去更改其它的对象。
如果我们能做到这一点，我们的系统当然是可维护性好、易变更性好的系统。
那么，我们如何做到高内聚呢？就拿前面我提到的评审项目举例。
我现在要为“评审表”对象编写一段填写并保存评审表的代码。
评审表对象的职责是更新和查询评审表的数据，但是在显示一个要填写的评审表的时候，我需要显示该评审计划的名称、该评审计划有哪些评审对象需要评审。
现在我如何编写显示一个要填写的评审表的代码？我在评审表对象的这个相应的函数中编写一段查询评审计划和评审对象的代码吗？假如你这样做了，你的代码就不是高内聚的，因为查询评审计划和评审对象的数据不是它的职责。
正确的方法应当去请求“评审计划”对象和“评审对象”对象来完成这些工作，而“评审表”对象只是获取其结果。
另外，如果一个对象要完成一个虽然在自己职责范围内，但过程非常复杂的任务时，也应当将该任务分解成数个功能相对独立的子函数来完成。
我曾经看见一个朋友写的数百行的一个函数，让人读起来非常费劲。
同时这样的函数中一些相对独立的代码，本可以复用到其它代码中，也变成了不可能。
所以我给大家的建议是，不要写太长的函数，超过一百行就可以考虑将一些功能分解出去。
与“低耦合”一样，高内聚也不是一个绝对，而是一个相对的指标，应当适当而不能过度。
正如我们在现实生活中，如果在一个十来人的小公司，每个人的分工可能会粗一些，所分配的职责会广一些杂一些，因为其总体的任务少；而如果在一个一两百人的大公司，每个人的分工会细一些，所分配的任务会更加专一些，因为总体任务多，更需要专业化的分工来提高效率。
软件开发也是一样，如果“评审计划”对象完成的业务功能少，并且不复杂，它完全可以代理它的子表“评审对象”和“评审者”的管理。
但是“评审计划”对象需要完成的“对评审计划表的管理”这个基本职责包含的业务功能繁多或者复杂，它就应当将“对评审对象表的管理”交给“评审对象”对象，将“对评审者表的管理”交给“评审者”对象。
同样，高内聚的可维护性好、易变更性好只能是一个相对的指标。
如果一个变更的确是大范围的变更，你永远不可能通过内聚就不进行大范围的变更了。
同时内聚也是要付出代价的，所以你也不必要去为了一个不太可能的变更去进行过度设计，应当掌握一个度。
过度的内聚必将增加系统中元素之间的依赖，提高耦合度。
所以“高内聚”与“低耦合”是矛盾的，必须权衡利弊，综合地去处理。
在李洋等人翻译的《UML和模式应用》中，将内聚和耦合翻译为软件工程中的阴与阳，是中国人对内聚和耦合的最佳解释。
综上所述，“高内聚”给软件项目带来的优点是：可读性强、易维护和变更、支持低耦合、移植和重用性强。
一个优秀软件开发人员的必修课：GRASP（2）低耦合关键字: 设计模式我偶然在google或yahoo这样的搜索引擎搜索GRASP发现，除了国外的网站，国内网站多介绍和讨论GoF而很少介绍GRASP，即使这少量的文章也讲解非常粗略。
个人认为作为优秀的开发人员，理解GRASP比GoF更重要，故写此文章。
前面我在《（原创）一个优秀软件开发人员的必修课：GRASP软件开发模式浅析》中介绍了使用GRASP的目的，今天允许我调换一下顺序，先从低耦合讲起，因为诸如创建者模式、信息专家模式的根本目的就是降低耦合。
1. 低耦合（Low Coupling）“低耦合”这个词相信大家已经耳熟能详，我们在看spring的书籍、MVC的数据、设计模式的书籍，无处不提到“低耦合、高内聚”，它已经成为软件设计质量的标准之一。
那么什么是低耦合？耦合就是对某元素与其它元素之间的连接、感知和依赖的量度。
这里所说的元素，即可以是功能、对象（类），也可以指系统、子系统、模块。
假如一个元素A去连接元素B，或者通过自己的方法可以感知B，或者当B不存在的时候就不能正常工作，那么就说元素A与元素B耦合。
耦合带来的问题是，当元素B发生变更或不存在时，都将影响元素A的正常工作，影响系统的可维护性和易变更性。
同时元素A只能工作于元素B存在的环境中，这也降低了元素A的可复用性。
正因为耦合的种种弊端，我们在软件设计的时候努力追求“低耦合”。
低耦合就是要求在我们的软件系统中，某元素不要过度依赖于其它元素。
请注意这里的“过度”二字。
系统中低耦合不能过度，比如说我们设计一个类可以不与JDK 耦合，这可能吗？除非你不是设计的Java程序。
再比如我设计了一个类，它不与我的系统中的任何类发生耦合。
如果有这样一个类，那么它必然是低内聚（关于内聚的问题我随后讨论）。