是否应该始终禁止受保护的属性？

Question

我很少使用继承，但是当我这样做时，我从不使用受保护的属性，因为我认为它破坏了继承类的封装。

你使用受保护的属性吗？ 你用它们做什么？

Answer 1

在 Bill Venners 对设计的采访中， Effective Java的作者 Joshua Bloch 说：

信任子类

Bill Venners：我应该比非子类更信任子类吗？ 例如，我是否让子类实现比非子类更容易破坏我？ 特别是，您如何看待受保护的数据？

Josh Bloch：假设您允许子类访问您的内部数据结构，编写既可子类化又可抵御恶意子类的东西实际上是一件非常困难的事情。 如果子类无法访问普通用户无法访问的任何内容，那么子类就更难造成损害。 但是，除非您将所有方法都设为 final，否则子类仍然可以通过在响应方法调用时做错误的事情来破坏您的契约。 这正是为什么像 String 这样的安全关键类是最终的。 否则，有人可以编写一个子类，使字符串看起来可变，这足以破坏安全性。 所以你必须信任你的子类。 如果你不信任它们，那么你就不能允许它们，因为子类很容易导致一个类违反它的契约。

就一般受保护的数据而言，这是一种必要的邪恶。 它应该保持在最低限度。 大多数受保护的数据和受保护的方法相当于对实现细节的承诺。 受保护字段是您使子类可见的实现细节。 即使是受保护的方法也是您让子类可见的一段内部结构。

让它可见的原因是为了让子类完成他们的工作，或者有效地完成工作，它通常是必要的。 但是一旦你做了它，你就会致力于它。 现在，您不允许更改某些内容，即使您后来找到了不再涉及使用特定字段或方法的更有效的实现。

因此，在所有其他条件相同的情况下，您根本不应该拥有任何受保护的成员。 但这就是说，如果您的数量太少，那么您的类可能无法用作超类，或者至少不能用作高效的超类。 通常你会在事后发现。 我的理念是在您第一次编写类时尽可能少地使用受保护的成员。 然后尝试对其进行子类化。 您可能会发现如果没有特定的受保护方法，所有子类都将不得不做一些坏事。

例如，如果您查看AbstractList ，您会发现有一种受保护的方法可以一次性删除列表的某个范围 ( removeRange )。 为什么会在里面？ 因为基于公共 API 删除范围的正常习惯用法是调用subList获取子List ，然后在该子List上调用clear 。 然而，如果没有这个特殊的受保护方法， clear唯一能做的就是反复删除单个元素。

想想看。 如果你有一个数组表示，它会做什么？ 它将反复折叠数组，执行 N 次工作 N 次。 因此，它将需要二次的工作量，而不是它应该的线性工作量。 通过提供这种受保护的方法，我们允许任何可以有效删除整个范围的实现这样做。 任何合理的List实现都可以更有效地一次性删除一个范围。

我们需要这种受保护的方法，你必须比我更聪明才能预先知道。 基本上，我实现了这件事。 然后，当我们开始对其进行子类化时，我们意识到范围删除是二次的。 我们负担不起，所以我输入了受保护的方法。 我认为这是使用受保护方法的最佳方法。 放入尽可能少的，然后根据需要添加更多。 受保护的方法代表对您可能想要更改的设计的承诺。 您始终可以添加受保护的方法，但不能将它们删除。

Bill Venners：还有受保护的数据？

Josh Bloch：同样的事情，但更多。 受保护的数据在弄乱数据不变量方面更加危险。 如果您让其他人访问某些内部数据，他们就可以自由支配这些数据。

简短版本：它破坏了封装，但它是一种必要的邪恶，应该保持在最低限度。

Answer 2

C＃：

我将 protected 用于我希望基类覆盖的抽象或虚拟方法。 如果它可以被基类调用，我也会使一个方法受到保护，但我不希望它在类层次结构之外被调用。

Answer 3

您可能需要它们作为静态（或“全局”）属性，您希望来自同一包（如果它是关于 java）的子类或类从中受益。

那些代表某种“常量值”的静态最终属性很少有 getter 函数，因此在这种情况下受保护的静态最终属性可能有意义。

Answer 4

Scott Meyers 说不要在 Effective C++（第 3 版）中使用受保护的属性：

第 22 条：将数据成员声明为私有。

原因与您给出的相同：它破坏了封装。 结果是，否则对类布局的局部更改可能会破坏依赖类型并导致许多其他地方发生更改。

Answer 5

protected关键字是一个概念错误和语言设计的缺陷，并且一些现代语言，例如 Nim 和 Ceylon（参见http://ceylon-lang.org/documentation/faq/language-design/#no_protected_modifier ），已经被仔细设计而不只是复制常见的错误，不要有这样的关键字。

破坏封装的不是受保护的成员，而是暴露不应该暴露的成员破坏了封装……无论它们是受保护的还是公开的都没有关系。 protected的问题在于它是错误的和误导性的......声明成员protected （而不是private ）并没有保护他们，它的作用正好相反，就像public一样。 可在类外访问的受保护成员暴露于世界，因此必须永远保持其语义，就像public的情况一样。 “受保护”的整个想法是无稽之谈......封装不是安全性，关键字只是进一步混淆了两者之间的混淆。 您可以通过避免在您自己的类中使用protected来提供一点帮助——如果某些东西是实现的内部部分，而不是类语义的一部分，并且将来可能会发生变化，那么将其设为私有或内部您的包、模块、程序集等。如果它是类语义中不可更改的部分，则将其公开，这样您就不会惹恼您的类的用户，他们可以看到文档中有一个有用的成员，但不能'不要使用它，除非他们正在创建自己的实例并且可以通过子类化来获得它。

Answer 6

我不在 Java 中使用受保护的属性，因为它们只在那里受到包保护。 但是在 C++ 中，我会在抽象类中使用它们，允许继承类直接继承它们。

Answer 7

拥有受保护的属性从来没有任何充分的理由。 基类必须能够依赖状态，这意味着通过访问器方法限制对数据的访问。 你不能让任何人访问你的私人数据，即使是孩子。

Answer 8

我最近参与了一个项目，“受保护”成员是一个非常好的主意。 类层次结构是这样的：

[+] Base
 |
 +--[+] BaseMap
 |   |
 |   +--[+] Map
 |   |
 |   +--[+] HashMap
 |
 +--[+] // something else ?

Base 实现了一个 std::list ，但没有别的。 用户禁止直接访问列表，但由于 Base 类不完整，它无论如何都依赖派生类来实现对列表的间接访问。

间接性可能来自至少两种风格：std::map 和 stdext::hash_map。 这两个映射的行为方式相同，但事实上 hash_map 需要 Key 是可散列的（在 VC2003 中，可投射到 size_t）。

所以 BaseMap 实现了一个 TMap 作为模板类型，它是一个类似地图的容器。

Map 和 HashMap 是 BaseMap 的两个派生类，一个专门用于 std::map 上的 BaseMap，另一个专门用于 stdext::hash_map。

所以：

• Base 不可用（没有公共访问器！），只提供通用功能和代码

• BaseMap 需要轻松读/写 std::list

• Map 和 HashMap 需要对 BaseMap 中定义的 TMap 进行简单的读/写访问。

对我来说，唯一的解决方案是对 std::list 和 TMap 成员变量使用 protected。 我无法将这些“私有”放置，因为无论如何我都会通过读/写访问器公开它们的所有或几乎所有功能。

最后，我想如果你最终将你的类划分为多个对象，每个派生都会为其母类添加所需的功能，并且只有最派生的类才是真正可用的，那么 protected 就是要走的路。 “受保护成员”是一个类，因此几乎不可能“打破”这一事实，这有帮助。

但除此之外，应尽可能避免使用protected（即：默认使用private，必须公开方法时使用public）。

Answer 9

这取决于你想要什么。 如果您想要一个快速类，那么应该保护数据并使用受保护和公共方法。 因为我认为您应该假设从您的类派生的用户非常了解您的类，或者至少他们已经阅读了您要覆盖的功能的手册。

如果您的用户惹恼了您的课程，那不是您的问题。 每个恶意用户在覆盖您的一个虚拟时都可以添加以下行：

（C＃）

static Random rnd=new Random();
//...
if (rnd.Next()%1000==0) throw new Exception("My base class sucks! HAHAHAHA! xD");
//...

你不能密封每个类来防止这种情况。

当然，如果您想对某些字段进行约束，请使用访问器函数或属性或您想要的东西并将该字段设为私有，因为没有其他解决方案......

但我个人不喜欢不惜一切代价坚持 oop 原则。 尤其是使属性的唯一目的是使数据成员私有。

（C＃）：

private _foo;
public foo
{
   get {return _foo;}
   set {_foo=value;}
}

这是我个人的看法。

但是做你老板要求的事情（如果他想要私人领域而不是那样做。）

Answer 10

我在基类中使用受保护的变量/属性，我知道我不打算更改为方法。 这样，子类可以完全访问其继承的变量，并且没有（人为创建的）通过 getter/setter 访问它们的开销。 一个例子是使用底层 I/O 流的类； 几乎没有理由不允许子类直接访问底层流。

这适用于在基类和所有子类中以直接简单的方式使用的成员变量。 但是对于使用更复杂的变量（例如，访问它会导致类内其他成员产生副作用），直接访问的变量是不合适的。 在这种情况下，可以将其设为私有，而可以提供公共/受保护的 getter/setter。 一个例子是基类提供的内部缓冲机制，其中直接从子类访问缓冲区会损害基类用于管理它们的算法的完整性。

这是一个设计判断决定，基于成员变量的简单程度以及在未来版本中的预期。

封装很棒，但也可能走得太远。 我见过自己的私有方法只使用 getter/setter 方法访问其成员变量的类。 这有点矫枉过正，因为如果一个类不能用自己的私有数据信任自己的私有方法，那么它还能信任谁呢？

Answer 11

一般来说，不，您真的不想使用受保护的数据成员。 如果您编写 API，则更是如此。 一旦有人继承了您的课程，您就永远无法真正进行维护，也不会以某种奇怪且有时狂野的方式破坏它们。

Answer 12

我用它们。 简而言之，如果您想共享某些属性，这是一个好方法。 当然，您可以为它们编写 set/get 函数，但是如果没有验证，那又有什么意义呢？ 它也更快。

考虑一下：您有一个类，它是您的基类。 它有很多你不想在子对象中使用的属性。 您可以为每个函数编写一个 get/set 函数，或者您可以只设置它们。

我的典型示例是文件/流处理程序。 您想访问处理程序（即文件描述符），但又想对其他类隐藏它。 这比为其编写 set/get 函数要容易得多。

Answer 13

我认为受保护的属性是一个坏主意。 我使用CheckStyle与我的 Java 开发团队一起强制执行该规则。

Answer 14

一般来说，是的。 受保护的方法通常更好。

在使用中，通过为一个类的所有子级共享的对象使用受保护的最终变量，可以提供一定程度的简单性。 我总是建议不要将它与原语或集合一起使用，因为无法为这些类型定义契约。

最近，我开始将使用原始类型和原始集合所做的工作与使用结构良好的类所做的工作区分开来。 原语和集合应该始终是私有的。

此外，我开始偶尔公开公共成员变量，当它们被声明为 final 并且是不太灵活的格式良好的类（同样，不是基元或集合）。

这不是一些愚蠢的捷径，我非常认真地考虑了这一点，并认为公开对象的公共最终变量和 getter 之间绝对没有区别。