oop - 你什么时候停止封装？

Question

我在管理给定通用事务的持久性机制的边界类上有一些事件处理程序:

void MyBoundaryClass::MyEventHandler(...)
{
  //retrieve stuff from the UI
  //...
  //declare and initialize trasaction to persist
  SimpleTransaction myTransaction(.../*pass down stuff*/);
  //do some other checks
  //...
  //declare transaction persistor
  TransactionPersistor myPersistor(myTransaction, .../*pass down connection to DB and other stuff*/);
  //persist transaction
  try
  {
    myPersistor.Persist();
  }
  catch(...)
  {
    //handle errors
  }
}

使用某种 TransactionManager 来包装 SimpleTransaction 和 TransactionPERsistor 对象会更好吗？

是否有任何有用的经验法则可以理解我是否需要进一步的封装？

目前我遵循的经验法则是“如果方法变得太大 - 做点什么”。在处理边界事件处理程序时，有时很难在过程和面向对象之间找到正确的平衡。

有什么意见吗？

干杯

Answer 1

考虑到:

concept of encapsulation是关于定义一个容器，

面向对象设计基于消息传递(方法调用)的概念

我认为 API 很好地表明了新的高级封装的相关性(即新对象的定义)

如果这个新对象提供的服务(即 API)是一致的，并且在重新组合到一个特殊对象中时更好地暴露给程序的其余部分，那么一定要使用一个新对象。

否则，很可能是矫枉过正。

由于您公开了 公众 API 通过创建一个新对象， 的概念测试在那个新对象(和一些其他模拟对象)中可能更容易做到，而不是创建许多遗留对象来测试这些相同的操作。

在您的情况下，如果您想测试事务，您必须实际测试 MyBoundaryClass 的 MyEventHandler，以便从 UI 检索数据。

但是如果你定义了一个 TransactionManager，那你就有机会 不同架构级别的低耦合 (GUI 与数据)存在于 MyBoundaryClass 中，并将数据管理导出到专用类中。
然后，您可以在独立的测试场景中测试数据持久性，特别关注限制值、数据库故障、非标称条件等。

测试场景可以帮助您细化不同对象的凝聚力( Daok 提到的重点)。如果您的测试简单且连贯，那么您的对象很可能具有明确定义的服务边界。

因为可以说 Coupling and Cohesion are two cornerstones of OO Programming ，像 TransactionManager 这样的新类的凝聚力可以​​根据它将执行的操作集来评估。

Cohesive means that a certain class performs a set of closely related actions. A lack of cohesion, on the other hand, means that a class is performing several unrelated tasks. [...] the application software will eventually become unmanageable as more and more behaviors become scattered and end up in wrong places.

如果您将在几个不同地方实现的行为重新组合到您的 TransactionManager 中，那应该没问题，只要它的公共(public) API 代表事务涉及的明确步骤，而不是像各种实用程序函数那样的“关于事务的东西”。一个名字本身不足以判断一个类的凝聚力。需要名称及其公共(public) API 的组合。

例如，TransactionManager 的一个有趣方面是完全封装 Transaction 的概念，它将:

系统的其余部分几乎不知道，并且会降低其他类和“事务”之间的耦合

通过将其 API 集中在事务步骤(如 initTransaction()、persistTransaction()、...)周围来增强 TransactionManager 的内聚性，避免任何 Transaction 实例的任何 getter 或 setter。