耦合/内聚
虽然这个论坛上有很多很好的例子，其中包含耦合和内聚的例子，但我正在努力将其完全应用到我的代码中。我可以识别代码中可能需要更改的部分。任何 Java 专家都可以看一下我的代码并向我解释哪些方面是好是坏。我完全不介意自己改变它。只是很多人似乎彼此不同意，我发现很难真正理解应该遵循什么原则......
Whilst there are many good examples on this forum that contain examples of coupling and cohesion, I am struggling to apply it to my code fully. I can identify parts in my code that may need changing. Would any Java experts be able to take a look at my code and explain to me what aspects are good and bad. I don't mind changing it myself at all. It's just that many people seem to disagree with each other and I'm finding it hard to actually understand what principles to follow...
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
首先，我想说，你得到如此不同答案的主要原因是，随着时间的推移，这确实成为一门艺术。你得到的许多意见并不能归结为严格的规则或事实，更多的是归结为一般经验。这样做 10 到 20 年后，你会开始记住你所做的哪些事情导致了疼痛，以及你如何避免再次这样做。许多答案都适用于某些问题，但个人的经验决定了他们的观点。
我实际上只需要更改您的代码中的一件非常重要的事情。我会考虑研究所谓的命令模式。有关这方面的信息应该不难在网上或 GoF 书中找到。
主要思想是每个命令“添加子项”、“添加父项”成为一个单独的类。单个命令的逻辑包含在一个易于测试和修改的小类中。然后应该“执行”该类来完成主类中的工作。这样，您的主类只需处理命令行解析，并且可能会丢失大部分 FamilyTree 知识。它只需要知道什么命令行映射到哪些命令类并启动它们。
这是我的2分钱。
First, I'd like to say that the primary reason you get such varying answers is that this really does become an art over time. Many of the opinions you get don't boil down to a hard fast rule or fact, more it comes down to general experience. After 10-20 years doing this, you start to remember what things you did that caused pain, and how you avoided doing them again. Many answers work for some problems, but it's the individual's experience that determines their opinion.
There is really only 1 really big thing I would change in your code. I would consider looking into what's called the Command Pattern. Information on this shouldn't be difficult to find either on the web or in the GoF book.
The primary idea is that each of your commands "add child", "add parent" become a separate class. The logic for a single command is enclosed in a single small class that is easy to test and modify. That class should then be "executed" to do the work from your main class. In this way, your main class only has to deal with command line parsing, and can lose most of it's knowledge of a FamilyTree. It just has to know what command line maps into which Command classes and kick them off.
That's my 2 cents.
我可以推荐 Alan 和 James 的书设计模式解释——对象的新视角面向设计 (ISBN-13: 978-0321247148):
这是一本关于has-a和is-a决策的好书，包括面向对象设计中的内聚和耦合。
I can recommend Alan's and James's book Design Patterns explained -- A new perspective on object-oriented design (ISBN-13: 978-0321247148):
It's a great book about has-a and is-a decissions, including cohesion and coupling in object-oriented design.
简而言之：
软件工程中的内聚力，就像在现实生活中一样，是指构成一个整体（在我们的例子中，我们假设是一个类）的元素在多大程度上可以说它们实际上属于在一起。因此，它是衡量软件模块源代码所表达的每项功能的相关程度的指标。
从面向对象的角度看待内聚性的一种方法是类中的方法是否使用任何私有属性。
现在的讨论比这更大，但高内聚（或内聚的最佳类型 - 功能内聚）是指模块的各个部分被分组，因为它们都有助于模块的单个明确定义的任务。
用简单的话来说，耦合是一个组件（再次想象一个类，尽管不一定）对另一个组件的内部工作或内部元素了解多少，即它对另一个组件有多少了解。
松耦合是一种将系统或网络中的组件互连的方法，以便这些组件在实际可能的最小程度上相互依赖......
长话短说：
我写了一篇关于此的博客文章。它详细讨论了所有这些，并附有示例等。它还解释了为什么您应该遵循这些原则的好处。我认为这可以帮助...
In short:
Cohesion in software engineering, as in real life, is how much the elements consisting a whole(in our case let's say a class) can be said that they actually belong together. Thus, it is a measure of how strongly related each piece of functionality expressed by the source code of a software module is.
One way of looking at cohesion in terms of OO is if the methods in the class are using any of the private attributes.
Now the discussion is bigger than this but High Cohesion (or the cohesion's best type - the functional cohesion) is when parts of a module are grouped because they all contribute to a single well-defined task of the module.
Coupling in simple words, is how much one component (again, imagine a class, although not necessarily) knows about the inner workings or inner elements of another one, i.e. how much knowledge it has of the other component.
Loose coupling is a method of interconnecting the components in a system or network so that those components, depend on each other to the least extent practically possible…
In long:
I wrote a blog post about this. It discusses all this in much detail, with examples etc. It also explains the benefits of why you should follow these principles. I think it could help...
耦合定义了系统中每个组件依赖于其他组件的程度。给定两个组件 A 和 B，如果 A 发生更改，B 中的代码必须更改多少。
内聚性定义了单个软件组件的各种功能的连贯性或强相关性的度量。它指的是类的作用。
低凝聚力意味着班级会采取各种各样的行动，而不是专注于应该做的事情。高内聚意味着类专注于它应该做的事情，即只关注与类的意图相关的方法。
注意：好的 API 表现出松耦合和高内聚性。
应始终避免的一种特别令人厌恶的紧耦合形式是具有两个直接或间接相互依赖的组件，即依赖循环或循环依赖。
详细信息在下面的链接
http://softwarematerial.blogspot.sg/2015/12/coupling-and -cohesion.html
Coupling defines the degree to which each component depends on other components in the system. Given two components A and B ,how much code in B must change if A changes.
Cohesion defines the measure of how coherent or strongly related the various functions of a single software component are.It refers to what the class does.
Low cohesion would mean that the class does a great variety of actions and is not focused on what it should do. High cohesion would then mean that the class is focused on what it should be doing, i.e. only methods relating to the intention of the class.
Note: Good APIs exhibit loose coupling and high cohesion.
One particularly abhorrent form of tight coupling that should always be avoided is having two components that depend on each other directly or indirectly, that is, a dependency cycle or circular dependency.
Detailed info in below link
http://softwarematerial.blogspot.sg/2015/12/coupling-and-cohesion.html