0

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

Connection c = driver.getConnection();
  1. 回馈联系
  2. 如果失败则报告错误
  3. 不要做超出预期的事情

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

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

session.connect(); //session is of Session type, my "business logic class"

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

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

 public class Session {
        ...
        Connection c;
        public void connect() {
             c = driver.getConnection();
        }      
 }

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

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

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

这正是我的观点。

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

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

我的想法是：

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

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

4

2 回答 2

1

我认为您缺少 OOP 概念和良好设计中的某些部分。如果您的代码不再可读——正如 Martin Fowler 所说，如果你的代码有异味——因为你试图增加内聚或减少耦合（你不能将耦合移除到 %0 或者你不能将内聚提高到 100%。当你尝试这个时，你会得到一个类似上面的 connect() 示例的代码），你走错了路。因为，这些概念的存在是为了使您的代码更具可读性。还有诸如“提取方法”之类的重构概念以增加凝聚力。Cohesion 和 Coupling 通常与形容词“低耦合”和“高内聚”一起使用。它们必须有多低或多高，设计师必须决定/优化它。顺便说一句，如果您 session.connect() 调用，我不希望必须配置连接。去做这个，

于 2011-05-29T22:37:36.997 回答
1

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

我认为这不能以任何有意义的方式回答。

正如@Erhan 的回答所指出的那样，凝聚力和耦合是与其他措施以及设计原则（OO 和其他）“紧张”的措施。如果您忽略常识并尝试孤立地最大化/最小化这些措施，您最终会得到不可读的代码。

IMO，最好的方法是对什么使您的代码可读和您的设计易于理解形成良好的直觉。请注意各种措施，但如果它们与您的直觉相矛盾，请准备好忽略它们。如果您不确定自己的直觉是否正确，请让更有经验的开发人员检查您的工作。

永远记住，各种度量（内聚、耦合、复杂性、测试覆盖率）都是经验性的，“好的设计”和“最佳实践”也是如此。他们忽略了你试图解决的问题的现实。不要用它们作为不思考和使用判断的借口。

于 2011-05-29T23:51:56.667 回答