Question

当您从库中调用方法时，您希望它完全符合其名称所暗示的方法。

Connection c = driver.getConnection();

回馈连接
如果失败则报告错误
不要做超出预期的事情

当编写“库代码”时，很容易坚持解耦，凝聚，抽象原则。大多数情况下，不遵守这些意味着设计中的错误。

但是当你处于商业逻辑中时，会出现一些困难，也许必须改变观点。在业务逻辑层面，我说：

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

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

如果你说一个方法不应该做所有这些东西，因为它必须具有凝聚力，并严格应用，你最终会得到一个只有一行的连接方法：

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

也就是说，业务类Session的方法connect将折叠为基础类。

其余的任务？阅读文件，检查db版本等？

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

这正是我的观点。

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

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

我的想法是：

凝聚力必须用一个全新的概念替换
凝聚力必须“拉伸”到某一点

既然我更喜欢第二种，我的问题就是这一点。

Answer 1

我认为你缺少OOP概念和优秀设计中的一些部分。如果您的代码不再可读 - 正如Martin Fowler所提到的那样，如果您的代码闻起来 - 因为您试图增加内聚力或减少耦合（您无法移除耦合到％0或者您无法将内聚力提高到100％。当你尝试这个时，你得到的代码就像上面的connect（）例子一样，你的方法是错误的。因为，这些概念可以使您的代码更具可读性。还有一些重构概念，如“提取方法”，以增加凝聚力。内聚和耦合通常与形容词一起使用，即“较低的耦合”和“较高的内聚力”。它们必须有多低或多高，设计师必须决定/优化它。顺便说一句，如果你调用session.connect（），我不希望必须配置连接。要做到这一点，还有许多其他概念，如连接工厂，会话管理器和公司。如果连接一旦配置，那么您可以调用connect（）方法来建立与设备（数据库）的物理连接。

Answer 2

由于我更喜欢第二种，我的问题是这一点。

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

正如@ Erhan的答案指出的那样，Cohesion and Coupling是与其他措施“紧张”的措施，以及设计原则（OO和其他）。如果忽略常识并尝试单独最大化/最小化这些度量，则最终会得到不可读的代码。

IMO，最好的方法是对你的代码可读性和设计易于理解的内容有一个很好的直觉。注意各种措施，但如果它们与你的直觉相矛盾，就要准备好忽视它们。如果您不确定自己的直觉是否正确，请让经验丰富的开发人员审核您的工作。

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

业务逻辑类中的抽象

2 个答案: