让字段受到保护是一个好主意吗?

代码示例:

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访问它吗?

你如何处理这种情况? 是否有任何性能方面的考虑?


尽管我同意你可以从最小特权开始,并在需要时将事物向可见性方向移动,但这只是因为它最终会产生适当的面向对象设计,而不必过多地考虑类成员是否是一个真正的业务函数应该暴露。

您应该在对象中尽可能多地封装和隐藏复杂性,以便外部接口尽可能简化。 完成此操作的一种方法是只根据需要添加或显示属性。

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

在这种情况下,因为TBar从TFoo继承,所以Protected是有效的可见性级别,因为它是为继承类保留的。 另外,因为TBar是从TFoo继承的,也许你认为它应该对TFoo的内部工作有一些额外的特权,因为它毕竟是它的子类。 为什么我们应该将TBar与其他类一样具有相同的低访问级别?

答案取决于FList是否是TFoo的实际类成员,因为我们考虑TFoo模型代表什么,或者它是否仅仅是实现细节。 另外,需要的访问级别是多少? 我们是简单地访问它,还是我们正在改变实现?

我猜你不需要访问FList,而且你也不会改变实现,在这种情况下,即使两个类在同一个单元中,我仍然会使FList专用于保护。

如果你只是从同一单位内的后代类访问类成员,我仍然保持私密。

但是,如果FList是你需要在TBar中重写的东西(可能不是,因为它不是方法),或者被设计成继承类应该或将会覆盖的东西,无论它是否在同一个单元中,那么你会希望使其受到保护。

如果您需要从同一单元之外的后代类访问FList,则还需要将可见性提高到Protected。

链接地址: http://www.djcxy.com/p/10339.html

上一篇: Is it a good idea to make fields protected?

下一篇: fileupload control in C# for videos