问题标签 [cohesion]

我目前正在创建一个简单的基于控制台的游戏，其中玩家可以在不同的房间之间移动，拿起和使用物品，以及吃东西。在游戏的当前状态下，就是这样。

我需要帮助的是：

为我的游戏创建一个好的“事件”类。我希望它的工作方式是每个项目和房间都应该能够与一个事件相关联。

由于我是新手，因此我将不胜感激与此类程序相关的任何阅读材料，或关于如何最好地考虑以下几点来设置我的课程的建议，或者只是如何攻击这种程序的问题（即难以决定如何设置课程）。

我希望能够创建不同类型的事件，例如：

• 输出一些文字，然后问玩家一个问题。如果玩家给出了正确的答案，就做点什么。

• 输出一些文本，然后从玩家的物品栏中移除一个物品，然后将玩家移动到另一个房间。

我试图避免的事情：

• 整个游戏的重点是练习良好的类设计，因此诸如责任驱动设计、内聚和耦合等方面是重要的方面。因此，我希望它尽可能简单、可重用和独立。

• 必须对每个事件进行硬编码，以便项目或房间只需调用 Event 类中的特定方法。

我此刻在想什么：

创建一些子类，以便我可以使用例如创建新事件（并将它们关联）： itemObject.setEvent(new Event(new Question("introText", "outroText", "correctAnswer")));

如果需要更多信息，请告诉我！谢谢！

说到面向对象的设计，你认为给一个对象一个将自己保存到数据库中的功能会破坏类的凝聚力吗？

想象：

您是否认为将这个产品 p 保存到 DataBase 最好以这种方式完成：

或以这样的方式：

你怎么看？

我已经使用 Java 编写了一个任务管理器程序，并暂时制作了一个 UI 实现。该程序目前有 3 层。通过用例控制器与域层交互的表示层，最后是用于持久性的技术服务层。在这一点上，用户可以执行多种操作，例如添加任务、编辑任务状态等……我在此方案中记录器的目的是跟踪用户执行的所有操作。所以，有几个地方我可以调用记录器来编写命令。我不会在表示层中进行任何日志记录，因为这将是一个糟糕的设计决策，所以我只剩下控制器、命令接口（为了实现撤消/重做功能而实现处理所有命令的执行） ),

我认为控制器是一个相对不错的选择，因为它充当 UI 层和域之间的联系点，因此所有值得注意的命令最终都通过控制器，从而可以轻松验证所有重要方法是否正在被记录. 不在控制器中这样做的一个原因是它会降低内聚，增加耦合并可能导致控制器臃肿。

具体命令是另一个潜在的位置，因为它们也具有日志记录所需的所有信息。这将再次导致命令变得不那么内聚并增加耦合。此外，如果我不使用命令界面对域对象执行操作，那么我会丢失日志记录。

最后，这导致我在较低级别的域对象方法中实现记录器。这是一个很好的选择，因为如果正在使用该程序并且所有需要的信息都可用，那么日志总是会发生。唯一不利的部分是记录器命令将稀疏地分散在较低级别的域对象中，这使得确保记录所有正确的方法变得更加困难。

我很乐意就此类决定进行辩论，并感谢您的所有评论。

虽然这个论坛上有很多很好的例子，其中包含耦合和内聚的例子，但我正在努力将它完全应用到我的代码中。我可以识别代码中可能需要更改的部分。是否有任何 Java 专家能够查看我的代码并向我解释哪些方面是好的和坏的。我完全不介意自己改变它。只是很多人似乎彼此不同意，我发现很难真正理解要遵循的原则......

我正在用 Python 编写一小段代码，很好奇其他人对此有何看法。

我有几个类，每个类都有几个方法，并且试图确定什么是“更好”：通过方法调用传递对象，或者在只需要来自对象的一个​​方法时通过方法调用传递方法。基本上，我应该这样做：

或这个

在我看来，第二个可以说是“更好”，因为它促进了操作和其他类之间更松散的耦合/更强的凝聚力。对于对象只需要一个方法的情况，我很想看到一些支持和反对这种方法的论据。

编辑：我删除了 OOP 措辞，因为它显然令人不安。我主要指的是松散耦合和高内聚。

模块有耦合和内聚。好的。有功能衔接和沟通衔接。功能内聚是按功能分组的。好的。通信凝聚力是按输入/输出数据分组的..嗯..不好。谁能解释一下什么是通信凝聚力或/并提供示例（任何语言，但最好使用 Java）？

假设我分别有 A、B 和 C 类的 doA()、doB() 和 doC() 方法。

除非我错了，否则 doA() 方法应该属于 A 类。它必须从 A 类执行。如果为 A 负责的方法 doA() 存在于 B 类中。那么 A 类与 B 的服务耦合. 这也代表低内聚和高耦合

我的推理正确吗？

我有保存到数据库的持久对象（插入、更新、删除）。将这种逻辑组合在一个方法中是否更好 - 保存或有 3 个单独的凝聚方法？

当您从库中调用方法时，您期望它完全按照其名称所暗示的那样执行。

1. 回馈联系
   
2. 如果失败则报告错误
   
3. 不要做超出预期的事情
   

在编写“库代码”时，很容易坚持解耦、内聚、抽象原则。不遵守这些，大多数时候，意味着设计上的错误。

但是当你在业务逻辑中时，会出现一些困难，也许必须改变视角。在业务逻辑级别，我说：

我希望它读取配置文件，如果没有找到它，则采用默认值，连接，进行一些检查，决定需要通知用户哪个警告，例如数据库版本比客户端旧的事实软件。

如果你说一个方法不应该做所有这些事情，因为它必须是内聚的，并且严格地应用它，你最终会得到一个只有一行的 connect 方法：

也就是connect业务类Session的方法会塌陷到底层类。

剩下的任务呢？读取文件，检查数据库版本等？

您将业务代码推迟到将执行所有逻辑的“大方法”。

这正是我的观点。

如果您在业务逻辑上下文中应用内聚和解耦原则，您将无法将任务细分为更小的子任务，并且您将拥有一些大型“单体”方法来完成所有工作并且可读性差。

我发现低级库（Driver.getConnection()）的良好原则（内聚力、抽象）对于业务逻辑来说是不够的。

我的想法是：

1. 凝聚力必须被一个全新的概念取代
   
2. 凝聚力必须“拉伸”到某个点
   

既然我更喜欢第二个，我的问题是那点是什么。