Question

我有一个＆＃34; uObjects＆＃34;单元。它有几个不同类型的对象，可以扩展TCollection / TCollectionItem。有一次将所有这些小小的课程分组在一个文件中可能会有很大的意义，因为事情很小而且它们有点相关，然后你就不会有令人担忧的bajillion文件。

但随着时间的推移，越来越多的方法被添加到这些集合中，使得管理变得更加困难，所以我想将uObjects单元拆分成多个更小的单元，以使其更易于维护。

但在此之前，我想知道是否有任何我应该知道的警告。这是我应该继续前进而不放弃的事情吗？或者我是否有任何理由（可能在某些情况下）不想将一个单位的无关部分分解成多个单元？这可能会引发问题吗？我仍然试图围绕来自Java世界的单元的细微差别，其中在单个文件中具有多个类通常不是一种选择。

Answer 1

主要问题是循环依赖。假设你有这些类：

type
  TClass2 = class;

  TClass1 = class
    FObj1 = TClass2;
  end;

  TClass2 = class
    FObj2 = TClass1;
  end;

如此处所述，循环依赖关系将这些类绑定在同一文件中。这是因为循环依赖只能通过前向声明来实现。并且前向声明不能应用于多个文件。

您可能遇到的另一个问题是私人和受保护的会员可见性。在同一文件中，该文件中定义的私有成员和受保护成员始终对该文件中的其他代码可见。这是普通可见性规则的一个特殊例外，它是Delphi的一个特性。

当您将类移动到不同的文件时，您可能会发现编译因其他类中的私有和受保护成员不再可见而失败。

关于类/文件关系的Delphi习语与Java相比有所不同。密切配合的类通常在同一文件中定义。另一方面，如果A类在没有B类知识的情况下存在，那么这两个类通常可以放在不同的文件中。

Answer 2

根据您的Delphi版本，您可以将所有集合放在一起，转而使用泛型。你会保留稍微重新设计的收藏品并将其放入TList（或类似的）中。

一旦你这样做，你会发现你将失去大多数小班（即TCollections）。我会把剩下的分成不同的单位。

使用TCollection时，我发现这主要是因为仿制药还没有。

一个小例子：

TMyCollectionItem = class(TCollectionItem)
  // Declarations
end;

TMyCollection = class(TCollection)
  // Declarations
end;

var
  MyCollection: TMyCollection;

/***************************/
// would become the following
/***************************/

TMyItem = class
  // Less declarations, as the typical TCollectionItem overrides are no longer required.
end;

var
  MyCollection: TList<TMyItem>;

我发现这清理了很多代码。

不将小（ish）类拆分为单独文件的优点？

2 个答案: