In computer programming, cohesion is a measure of how strongly-related and focused the various responsibilities of a software module are. Cohesion is an ordinal type of measurement and is usually expressed as "high cohesion" or "low cohesion" when being discussed.
Modules with high cohesion tend to be preferable because high cohesion is associated with several desirable traits of software including robustness, reliability, reusability, and understandability whereas low cohesion is associated with undesirable traits such as being difficult to maintain, difficult to test, difficult to reuse, and even difficult to understand.
I had Code Complete by Steve McConnell next to my computer (ie the programmers bible) with the page open explaining cohesion so I thought I'd share,
Cohesion arose from structured design and is usually discussed in the same context as coupling. Cohesion refers to how closely all the routines in a class or all the code in a routine support a central purpose-how focused the class is. Classes that contain strongly related functionality are described as having strong cohesion, and the heuristic goal is to make cohesion as strong as possible.
I use the term “separation of concerns” to explain this while refactoring. Often when code is fairly new, things will get lumped in together as the separate concerns are not clear at first.
One easy way to illustrate this to your co worker would be to ask them to write test cases for the code. This should illustrate that the code is not clear or coherent.
Another good phrase to use is that functions/objects “should do one thing, and do it well”, this has implications in everything from the object/method names to the overall architecture of the system.
In addition to the answers given so far, a simple way to think of high cohesion is lack of duplication of functionality, and clear seperation of related functionality into distinct modules, components or classes. Thus if you want a function similar to another function, and you cut and paste and subsequently modify a copy of the code, you are reducing cohesion. If you modify the the original to handle the new case, where the new case is clearly related to the existing functionality, you are increasing cohesion. Put another way, if your program has to do a given thing, no matter how times or in how many places, for maximum cohesion there should only be once piece of code that does that thing. At the same, a given class, module or component should have a single area of responsibility. Lumping unrelated functionality into a single class or component also reduces cohesion.
As CodeWiki says, cohesion is typically discussed with coupling, where the two can act in opposition to one another, particularly where strict interfaces aren't carefully planned. Many of the googled articles on cohesion relate to OO design, but cohesion and coupling are not restricted to OO.
发布评论
评论（5）
我认为正确的术语是内聚。
I think the correct term is cohesion.
我的电脑旁边有 Steve McConnell 的《Code Complete》（即程序员圣经），页面打开，解释了凝聚力，所以我想分享一下，
I had Code Complete by Steve McConnell next to my computer (ie the programmers bible) with the page open explaining cohesion so I thought I'd share,
我在重构时使用术语“关注点分离”来解释这一点。 通常，当代码相当新时，事情会被混在一起，因为各个问题一开始并不清楚。
向同事说明这一点的一种简单方法是要求他们为代码编写测试用例。 这应该说明代码不清晰或不连贯。
另一个好用的短语是函数/对象“应该做一件事，并且做好”，这对从对象/方法名称到系统整体架构的各个方面都有影响。
I use the term “separation of concerns” to explain this while refactoring. Often when code is fairly new, things will get lumped in together as the separate concerns are not clear at first.
One easy way to illustrate this to your co worker would be to ask them to write test cases for the code. This should illustrate that the code is not clear or coherent.
Another good phrase to use is that functions/objects “should do one thing, and do it well”, this has implications in everything from the object/method names to the overall architecture of the system.
除了到目前为止给出的答案之外，思考高内聚性的一个简单方法是缺乏功能重复，并将相关功能清晰地分离到不同的模块、组件或类中。 因此，如果您想要一个与另一个函数类似的函数，并且剪切和粘贴并随后修改代码副本，则会降低内聚性。 如果您修改原始版本来处理新案例，其中新案例与现有功能明显相关，那么您就增加了凝聚力。 换句话说，如果你的程序必须做一件给定的事情，无论多少次或在多少地方，为了最大的内聚性，应该只有一段代码来做这件事。 同时，给定的类、模块或组件应该有一个单一的职责范围。 将不相关的功能集中到单个类或组件中也会降低内聚性。
正如 CodeWiki 所说，内聚性通常与耦合一起讨论，两者可能相互对立，特别是在没有仔细规划严格接口的情况下。 谷歌搜索到的许多关于内聚的文章都与 OO 设计相关，但内聚和耦合并不局限于 OO。
In addition to the answers given so far, a simple way to think of high cohesion is lack of duplication of functionality, and clear seperation of related functionality into distinct modules, components or classes. Thus if you want a function similar to another function, and you cut and paste and subsequently modify a copy of the code, you are reducing cohesion. If you modify the the original to handle the new case, where the new case is clearly related to the existing functionality, you are increasing cohesion. Put another way, if your program has to do a given thing, no matter how times or in how many places, for maximum cohesion there should only be once piece of code that does that thing. At the same, a given class, module or component should have a single area of responsibility. Lumping unrelated functionality into a single class or component also reduces cohesion.
As CodeWiki says, cohesion is typically discussed with coupling, where the two can act in opposition to one another, particularly where strict interfaces aren't carefully planned. Many of the googled articles on cohesion relate to OO design, but cohesion and coupling are not restricted to OO.
以有序、逻辑和美观一致的各部分关系为标志； “一个连贯的论点” - 来自 http://www.websters-online-dictionary.org /定义/连贯
Marked by an orderly, logical, and aesthetically consistent relation of parts; "a coherent argument" - from http://www.websters-online-dictionary.org/definition/coherent