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 over Protected。

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

但是，如果你需要在TBar中覆盖FList（可能不是，因为它不是方法），或者设计为继承类应该或将覆盖的东西，无论它是否在同一个单元中，然后你会想让它受保护。

如果您需要从同一单元外的后代类访问FList，您还需要将可见性提高到受保护。

保护田地是个好主意吗？

1 个答案: