6

这更像是一个概念问题。我知道如何去做我想做的事。我想知道这是否是正确的做法。

我试图代表一些在现实生活中涉及到一些嵌套的东西。它是一个文档，它指定要使用一组项目执行的活动。一个文档可能涵盖多个项目，每个项目可能有多个活动。

所以层次结构将是 Document -> Item -> Activity。

我目前的想法是用一个顶级类 Document 来表示它，它包含一个内部类 ItemProgram，它本身包含一个内部类 Activity。是的，这是两层嵌套。

public class Document {

   // Properties of the document itself

   private Map<Item, ItemProgram> itemPrograms; // Map of item programs

   public class ItemProgram {

      // Properties of the item program itself

      private List<Activity> activities; // List of activities

      public class Activity {
         // Properties of the activity
      }
   }
}

内部类必须是公共的，但我将构造函数设为私有，以便它们仅由外部类中的 add 方法创建。如您所见，我使用 Collection 类型存储实例。

这是解决这个问题的正确方法吗？双重嵌套？

在外部类中使用集合来存储对内部类所有实例的引用是否合适？

4

2 回答 2

3

我明白你为什么想使用这个结构，但这不是我会选择的（当然没有绝对正确/错误的答案）。这里有几点需要考虑：

内部类实例将可以访问其封闭对象的内部状态，这对于您的示例可能不是必需的，并且会使类非常紧密地耦合。

这种方式的双重嵌套是“不寻常的”，可能会使阅读您的代码的其他人感到困惑。

将来，如果您的系统设计发生变化，并且可以独立于 Item 创建 Activity（例如），那么您将不得不在代码中执行一些大手术。

内部类的实例将使用对其父对象的隐式引用创建，您是否真的需要这个额外的引用（父母已经通过私有集合知道他们的孩子，它是否必须是双向关系，增加了一个一定程度的复杂性）？

你有没有想过这种设计会如何影响你代码的可测试性？如果您想对 Activity 类进行单元测试怎么办？您能否以这样的方式执行此操作，即测试失败肯定会表明 Activity 中存在问题，而不是其中一个父类中的问题？

于 2012-10-09T07:58:54.693 回答
1

这种特殊的方法很好，虽然每种都有一种类型，但请记住（并在注释中记录），如果您开始需要多种类型或派生类Document，Activity或者ItemProgram您很可能需要将此类拆分以使其更具可扩展性图案。

如果Document包含自己的逻辑，加上创建Activity实例的逻辑和创建实例的逻辑，ItemProgram则违反了SRP（单一责任原则）的指导。此原则可帮助您防止横向扩展问题并防止类爆炸，在这种情况下，您开始获取表示组合的类，而不是使用组合模式。

如果这些类的客户端只是父（封闭）类，我还会说嵌套类是可以的，如果您在其他地方使用它们，我会将它们分开。

编辑说了这么多，嵌套类比将它们作为单独的类没有任何好处，至少没有任何好处会对您正在开发的系统产生积极影响：

  • 隐藏的复杂性，其他开发人员会知道该文件包含三个类，而不是他们期望的一个。
  • 访问私有，父母可以访问嵌套的类变量以及相反的方式，无论哪种方式都不是预期的并且难以维护。
于 2012-10-09T07:57:21.740 回答