为什么面向对象语言真的需要 PROTECTED 访问修饰符？

Question

我可以理解为什么有 public 和 private 访问修饰符，这两个修饰符几乎在任何语言中都可以找到。我什至可以理解为什么可能有一个 package 修饰符，因为您可能希望让您的类（紧密属于在一起的类）以不适合公共交互的方式彼此交互（例如，因为它取决于类内部的知识，也许因为它会泄露一个秘密，或者可能因为它可能随时更改并且依赖它会破坏所有现有代码，等等）。但是，为什么我想要一个受保护的标识符？不要误会我的意思，我知道 protected 的含义，但是为什么我希望我的类的子类访问某些实例变量或使用某些方法，仅仅因为它们是子类，即使它们是子类的一部分不同的包？ protected 的真实用例是什么？

（并且性能作为实例变量的参数并不重要，因为 JIT 编译器始终可以内联访问器方法，将其调用开销减少到零）

Answer 1

公共方法是公共接口的一部分。私有方法是内部方法。受保护的方法是扩展点。

使用protected，您可以通过覆盖类来重新定义类的功能，而无需将此方法作为公共接口的一部分。

另一件事 - 受保护的方法是可以由子类重用的常见方法，但同样不需要成为公共接口的一部分。

例如，在java集合框架中，有AbstractList类。它具有受保护的 modCount 字段和受保护的 removeRange 方法：

• 所有子类都使用（递增）modCount 字段来计算数量的修改。 AbstractList 返回的 Iterator 使用该字段

  ，

• 子类可以重用 removeRange 方法，而不是让它们再次定义它.

查看 Josh Bloch 关于 API 设计的相关演示。

正如评论中和布洛赫的演示中所述 - 很好地记录你的课程。如果它是为了继承 - 付出额外的努力。

Answer 2

我看到的最常见的用法实际上是让超类使用子类的内部结构。考虑一下：

class Foo
{
    private int[] array = new int[] { 4, 3, 2, 1 };

    public void processAllElements()
    {
        for (int i = 0; i < array.length; i++)
            processElement(array[i]);
    }

    protected abstract void processElement(int i);
}

class Bar
{
    protected void processElement(int element)
    {
        System.out.println(element);
    }
}

在这种情况下，是 Foo 需要使用 Bar 的受保护元素，而不是相反。如果您希望超类访问子类的逻辑，但不希望它被公开暴露，那么您别无选择，只能使用 protected 修饰符。这称为模板方法模式，并且经常使用。 （很抱歉没有提供真实的示例。如果您需要一些，请前往维基百科。）

Answer 3

当你不完全了解可能的扩展者的想法时，我将它们视为一条捷径。假设您的基类有 5 或 6 个属性。您当然不希望这些属性（或其设置方法）公开。但您可以看到扩展程序可能想要编写可以更改这些属性值的函数。所以你要保护它们（或者更好的是它们的集合）。总是存在对设计的依赖，这对于扩展器来说可能是可以的，但对于任何旧的消费代码来说是不行的。

也就是说，我告诉我的学生“受保护是一个待办事项列表”。因为如果你改变任何受保护的东西，你必须去寻找谁依赖它。因此，在将某些东西暴露给未来未知的扩展者之前，请务必确定它。

Answer 4

事实上，存在没有 protected 访问修饰符的语言，甚至根本没有访问修饰符的语言，其中所有方法都是公共的，和< /em> 这些语言通常被认为是一些“最纯粹的” OO 语言，表明您实际上“并不真正需要”受保护的访问修饰符。

Answer 5

公共可继承类中的公共成员构成了与整个世界的契约，对所有行为良好的子类都有约束力。受保护的成员与任何直接子类构成契约，该契约仅对公开它的类具有约束力。子类没有义务向它们自己的子类公开任何受保护的成员（实际上，应该有一个拒绝此类公开的约定，以及指定特定受保护成员默认情况下仅可用于直接子类的方法，除非这些成员子类指定它也应该可供其子类使用）。

有些人可能会对类不允许访问其父类公开的受保护成员的想法感到恼火，但这种行为无论如何都不会违反里氏替换原则。 LSP 规定，如果代码在需要基类型对象时可以接收派生类型对象，则派生类型对象应该能够执行基类型对象可以执行的任何操作。因此，如果 Moe 公开支持某个功能和类型 Larry，而从 Moe 派生的 Larry 则不支持，则接受 Larry 类型参数的代码code>Moe 并尝试使用该功能，如果给它一个 Larry，就会失败；此类失败将构成对 LSP 的违反。

但是，假设 Moe 包含 Larry 不支持的受保护 功能。唯一允许使用该功能的类要么是直接派生自 Moe 的类，要么是来自支持该功能的 Moe 后代的类。如果 Curly 派生自 Moe，它可以使用该功能，而不必担心 Moe 的所有子类型是否都支持它，因为 Curly 的基础不会是任何 Moe 实例或派生对象（并且可能支持也可能不支持该功能）的任意对象 - 它将是一个 Moe，句号。

如果派生类型使用这些字段的方式破坏了使用它们的基类的公共成员，则受保护字段可能会引入一些与 LSP 相关的问题。另一方面，不需要为此使用受保护的变量。如果子类型以与基类型的预期行为不同的方式实现虚拟成员，则即使不触及任何基类受保护成员，也可能会破坏基类型的公共成员。

Answer 6

当我想要 a) 消除公共契约中的噪音，同时 b) 还与派生类共享功能，同时 c) 编写 DRY 代码并且同时注意单一职责原则时，我个人会使用 protected 修饰符。我确信这听起来很典型，但让我举一个例子。

这里我们有一个基本的查询处理程序接口：

public interface IQueryHandler<TCommand, TEntity>
{
    IEnumerable<TEntity> Execute(TCommand command);
}

该接口由应用程序中的许多不同查询处理程序实现。稍后假设我需要缓存来自许多不同查询处理程序的查询结果。但这实际上只是一个实现细节。一般来说，任何具体查询处理程序类的使用者都不关心这一点。我的解决方案是创建一个实现来处理缓存，但将实际查询责任推迟到任何派生类。

public abstract class CachedQueryHandler<TCommand, TEntity> 
    : IQueryHandler<TCommand, TEntity>
{
    public IEnumerable<TEntity> Execute(TCommand command)
    {
        IEnumerable<TEntity> resultSet = this.CacheManager
            .GetCachedResults<TEntity>(command);

        if (resultSet != null)
            return resultSet;

        resultSet = this.ExecuteCore(command);
        this.CacheManager.SaveResultSet(command, resultSet);

        return resultSet;
    }

    protected abstract IEnumerable<TEntity> ExecuteCore(TCommand command);
}

CachedQueryHandler 不打算让其他任何人直接调用 ExecuteCore 方法。它也不关心查询是如何实现的。 protected 修饰符非常适合这样的场景。

另外，我不想在每个查询处理程序中重复相同的样板类型的代码，特别是因为如果缓存管理器接口发生更改，那么重构将是一场噩梦，如果此时完全删除缓存，那么重构将是一场噩梦等级。

下面是具体的小部件查询处理程序的样子：

public class DatabaseWidgetQueryHandler : CachedQueryHandler<WidgetCommand, Widget>
{
    protected override IEnumerable<Widget> ExecuteCore(WidgetCommand command)
    {
        return this.GetWidgetsFromDatabase();
    }
}

现在，如果小部件查询处理程序的使用者通过查询处理程序接口使用它（如果我利用依赖注入，我当然可以强制执行），他们将永远不会使用任何特定于缓存的东西添加到 CachedQueryProvider 类中。然后，我可以根据需要随意添加/删除缓存，或者完全更改缓存实现，甚至只需付出最少的努力。

IQueryHandler<WidgetCommand, Widget> widgetQueryHandler;
var widgets = widgetQueryHandler.Execute(myWidgetCommand);

Answer 7

也许，您会与您的孩子分享一些信息/财产，即使他们已婚并居住在另一个国家。顺便说一句，有些语言没有 protected 修饰符。