保护田地是个好主意吗？

Question

代码示例:

unit Foo;

  TFoo = class
  protected
    FList: TList; // Lifetime is managed by constructor and destructor
  public
    property List: TList read FList;
    constructor Create;
    destructor Destroy; override;
  end;

unit Bar;

  TBar = class(TFoo)
    procedure MyMethod;
  end;

procedure TBar.MyMethod;
begin
  // Access of FList goes here
end;

TBar类能够直接修改FList的值,但这并不是绝对必要的,因为它只需调用其方法/使用其属性.

我应该将FList设为私有并使用该属性从TBar访问它吗？

你如何处理这样的案件？还有任何性能方面的考虑吗？

Answer 1

虽然我同意您可以从最小的特权开始，并在需要时将内容提升到可见性，但这只是因为它最终会产生正确的面向对象设计，而不必过多考虑类成员是否是真正的业务功能应该暴露。

您应该在对象中封装和隐藏尽可能多的复杂性，以便外部接口尽可能简约。实现此目的的一种方法是仅根据需要添加或公开属性。

如果您不需要对类的特定成员进行外部访问，那么它可能只是一个实现工件，并且不适合该类的实际业务用途。因此，它的复杂性应该被隐藏。

在本例中，由于 TBar 继承自 TFoo，因此 Protected 是有效的可见性级别，因为它是为继承的类保留的。另外，因为 TBar 是从 TFoo 继承的，所以您可能认为它应该对 TFoo 的内部工作拥有一些额外的特权，因为它毕竟是它的子类。为什么我们应该将 TBar 降级为与其他类具有相同的低级别访问权限？

答案取决于 FList 是否是 TFoo 的实际类成员（当我们考虑 TFoo 模型代表什么时），或者它是否只是一个实现细节。另外，所需的访问级别是多少？我们只是简单地访问它，还是改变实现？

我猜测您不需要访问 FList，并且您不需要更改实现，在这种情况下，即使这两个类位于同一单元中，我仍然会将 FList 设置为 Private 而不是 Protected。

如果您只是从同一单元内的后代类访问类成员，我仍然会将其保持为私有。

但是，如果 FList 是您需要在 TBar 中重写的内容（可能不需要，因为它不是方法），或者被设计为继承类应该或将重写的内容，无论它是否在同一单元中，那么您将想让它受到保护。

如果您需要从同一单元外部的后代类访问 FList，您还需要提高 Protected 的可见性。