Java 业务逻辑类中的抽象

当您从库中调用一个方法时，您希望它完全按照其名称所暗示的方式执行

Connection c = driver.getConnection();

返回连接

如果失败则报告错误

不要做超出预期的事

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

但是，当您处于业务逻辑中时，会出现一些困难，可能需要改变视角。在业务逻辑层面，我说：

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

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

如果您说一个方法不应该做所有这些事情，因为它必须是内聚的，并且严格地应用它，那么您将得到一个只包含一行的connect方法：

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

也就是说，业务类会话的方法

connect

将塌陷到底层类

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

您正在将业务代码推迟到一个“大方法”，它将完成所有逻辑。

这正是我的观点。

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

我发现底层库（Driver.getConnection（））的良好原则（内聚、抽象）对于业务逻辑来说是非常不充分的

我的想法是：

必须用一个全新的概念来取代凝聚力

内聚必须“延伸”到某一点

---

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

我认为您在OOP概念和优秀设计中缺少了一些部分。如果您的代码不再可读——正如Martin Fowler所提到的，如果您的代码有异味——因为您试图增加内聚或减少耦合（您无法删除到%0的耦合，或者您无法将内聚提高到100%。当您尝试此操作时，您会得到类似上面的connect（）示例的代码），那么您走错了路。因为，这些概念是为了让代码更具可读性。还有重构概念，如“提取方法”，以增强内聚性。衔接和联结通常与形容词“低联结”和“高联结”一起使用。设计人员必须决定/优化它们的高低。顺便说一下，如果您调用session.connect（），我不希望必须配置连接。为此，还有许多其他概念，如连接工厂、会话管理器和Co。如果一旦配置了连接，则可以调用connect（）方法来建立到设备（数据库）的物理连接

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

我认为这没有任何意义

正如@Erhan的回答所指出的，内聚和耦合是与其他度量以及设计原则（OO和其他）处于“紧张”状态的度量。如果您忽略了常识，并试图单独地最大化/最小化这些度量，那么最终将得到无法读取的代码

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

---

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

我同意你的看法。但我的问题不是重构我或我的团队编写的一些代码。我的问题是有一些标准来帮助设计选择。一些更客观的说法是“一个介于0%和100%之间的值”、“常识”和“直觉”以及“询问更多经验开发人员”。事实上，区分“库”代码和“业务逻辑”代码，并声明在库中您应该更加严格，这比您所说的更进一步：-）重构只是我回答中的一个例子。在软件设计中，有许多属性，如可扩展性、可读性、可测试性等，因为它们相互依赖。例如，当您使代码更易于阅读时，可能会降低可扩展性。我不认为有一个公式可以描述在减少%x内聚时代码必须具有多大的可扩展性。事实上，它可能不是一个公式，而是一组由用例和使用强制标准说明的模式。@AgistinoX-我已经回答了这个问题。请看我答案的第一句。最后一段是关于。。。即使这不是你想听的“魔弹”答案。哦，当然，你可以不同意，并为自己找到一个更好的方法来解决这个问题。好吧。让我解释一下为什么我不认为这是真的。用你的话来说，当一个“过期程序员”有“直觉”时，这不是表演“艺术”或魔术师。他只是把问题放在一个更广阔的领域里，从更多的元素出发进行逻辑演绎。我对这个逻辑感兴趣。把它拿出来。称之为“过期”意味着开发者头脑中的“黑匣子”。我敢肯定，如果我在构建模式的“想法”之前询问是否有构建对象的标准，许多人会说“取决于经验，没有有意义的答案”！直觉只是一种知识，它是如此的实用和根深蒂固，以至于它变得更像是一种感觉而不是感觉