为什么我们不应该在 java 中使用 protected static

Question

我正在回答这个问题Is there a way to override class variables in Java? 第一条获得 36 票的评论是：

如果您看到protected static，请运行。

谁能解释为什么protected static 不受欢迎？

Answer 1

与其说是直接的问题，不如说是风格上的问题。这表明你没有正确思考课堂上发生了什么。

想想static是什么意思：

这个变量存在于类级别，它不针对每个实例单独存在，并且它在扩展我的类中不独立存在。

想想protected是什么意思：

这个变量可以被这个类看到，同一个包中的类和扩展我的类。

这两个含义并不完全相互排斥，但非常接近。

我可以看到您可以将两者一起使用的唯一情况是，如果您有一个旨在扩展的抽象类，并且扩展类可以使用原始定义的常量修改行为。不过，这种安排很可能最终会变得非常混乱，并表明类的设计存在弱点。

在大多数情况下，将常量设为公开会更好，因为这只会使所有内容更整洁，并允许人们进行子类化具有更大的灵活性。在许多情况下，组合比继承更可取，而抽象类强制继承。

要查看一个如何破坏事物的示例并说明我所说的变量不具有独立存在的含义，请尝试以下示例代码：

public class Program {
    public static void main (String[] args) throws java.lang.Exception {
        System.out.println(new Test2().getTest());
        Test.test = "changed";
        System.out.println(new Test2().getTest());
    }
}

abstract class Test {
    protected static String test = "test";
}

class Test2 extends Test {
    public String getTest() {
        return test;
    }
}

你会看到结果：

test
changed

亲自尝试：https://ideone.com/KM8u8O

类Test2 能够从Test 访问静态成员test 而无需限定名称 - 但它不会继承或获取自己的副本。它正在查看内存中完全相同的对象。

Answer 2

静态成员不被继承，受保护的成员只对子类（当然还有包含的类）可见，所以protected static 与static 具有相同的可见性，这表明编码器存在误解。

Answer 3

我看不出有什么特别的理由不应该对此表示不满。可能总是有实现相同行为的替代方法，并且这些替代方法是否比受保护的静态方法“更好”取决于实际架构。但是，受保护的静态方法至少是合理的一个示例可能如下：

（编辑拆分成单独的包，使protected的使用更清晰）

package a;
import java.util.List;

public abstract class BaseClass
{
    public Integer compute(List<Integer> list)
    {
        return computeDefaultA(list)+computeDefaultB(list);
    }

    protected static Integer computeDefaultA(List<Integer> list)
    {
        return 12;
    }
    protected static Integer computeDefaultB(List<Integer> list)
    {
        return 34;
    }
}

由此而来：

package a.b;

import java.util.List;

import a.BaseClass;

abstract class ExtendingClassA extends BaseClass
{
    @Override
    public Integer compute(List<Integer> list)
    {
        return computeDefaultA(list)+computeOwnB(list);
    }

    private static Integer computeOwnB(List<Integer> list)
    {
        return 56;
    }
}

另一个派生类：

package a.b;

import java.util.List;

import a.BaseClass;

abstract class ExtendingClassB extends BaseClass
{
    @Override
    public Integer compute(List<Integer> list)
    {
        return computeOwnA(list)+computeDefaultB(list);
    }

    private static Integer computeOwnA(List<Integer> list)
    {
        return 78;
    }
}

protected static 修饰符在这里当然是合理的：

• 方法可以是static，因为它们不依赖于实例变量。它们不打算直接用作多态方法，而是提供默认实现的“实用”方法，这些实现是更复杂计算的一部分，并充当实际的“构建块”实施。
• 方法不应该是public，因为它们是一个实现细节。而且它们不能是private，因为它们应该被扩展类调用。它们也不能具有“默认”可见性，因为这样其他包中的扩展类将无法访问它们。

（编辑：可以假设原始评论仅涉及 fields，而不是 methods - 但是，它太笼统了）

Answer 4

使用受保护的，以便它可以在子类中使用。在具体类的上下文中使用时定义受保护的静态是没有逻辑的，因为您可以访问相同的变量是一种静态方式。但是编译器会警告以静态方式访问超类静态变量。

Answer 5

不赞成，因为它自相矛盾。

创建一个变量protected 意味着它将被在包中使用，或者它将被在子类中继承。

使变量static 使其成为类的成员，消除了继承它的意图。这仅留下了在包中使用的意图，我们为此提供了package-private（无修饰符）。

我觉得这很有用的唯一情况是，如果您声明了一个应该用于启动应用程序的类（如 JavaFX 的 Application#launch，并且只想能够从子类启动。如果这样做，确保该方法也是 final 以禁止 hiding。但这不是“规范”，可能是为了防止通过添加新的启动应用程序方式来增加复杂性而实现的。

要查看每个修饰符的访问级别，请参阅：The Java Tutorials - Controlling Access to Members of a Class

Answer 6

实际上protected static 并没有根本性的问题。如果你真的想要一个对包和声明类的所有子类可见的静态变量或方法，那么继续并使其成为protected static。

有些人出于各种原因一般避免使用protected，有些人认为非final的static变量应该尽量避免使用（我个人在一定程度上同情后者），所以我猜protected 和 static 对于属于这两个群体的人来说必须看起来糟糕^2。

Answer 7

拥有protected static 并没有错。许多人忽略的一件事是，您可能希望为在正常情况下不想公开的静态方法编写测试用例。我注意到这对于为实用程序类中的静态方法编写测试特别有用。

Answer 8

好吧，正如大多数人所回答的那样：

• protected 表示 - 'package-private + 对子类的可见性 - 属性/行为是继承的'
• static 表示 - '与实例相反 - 它是 CLASS 属性/行为，即它不是继承的'

因此它们有些矛盾和不相容。

但是，最近我想出了一个用例，将这两者结合使用可能是有意义的。想象一下，您想创建一个 abstract 类，它是 不可变 类型的父类，并且它具有许多子类型共有的属性。为了正确实现不变性并保持可读性，人们可能会决定使用Builder模式。

package X;
public abstract class AbstractType {
    protected Object field1;
    protected Object field2;
    ...
    protected Object fieldN;

    protected static abstract class BaseBuilder<T extends BaseBuilder<T>> {
        private Object field1; // = some default value here
        private Object field2; // = some default value here
        ...
        private Object fieldN; // = some default value here

        public T field1(Object value) { this.field1 = value; return self();}
        public T field2(Object value) { this.field2 = value; return self();}
        ...
        public T fieldN(Object value) { this.fieldN = value; return self();}
        protected abstract T self(); // should always return this;
        public abstract AbstractType build();
    }

    private AbstractType(BaseBuilder<?> b) {
        this.field1 = b.field1;
        this.field2 = b.field2;
        ...
        this.fieldN = b.fieldN;
    }
}

为什么是 protected static ？因为我想要一个AbstactType 的非抽象子类型，它实现了自己的非抽象生成器，并且位于package X 之外，以便能够访问和重用BaseBuilder。

package Y;
public MyType1 extends AbstractType {
    private Object filedN1;

    public static class Builder extends AbstractType.BaseBuilder<Builder> {
        private Object fieldN1; // = some default value here

        public Builder fieldN1(Object value) { this.fieldN1 = value; return self();}
        @Override protected Builder self() { return this; }
        @Override public MyType build() { return new MyType(this); }
    }

    private MyType(Builder b) {
        super(b);
        this.fieldN1 = b.fieldN1;
    }
}

当然，我们可以将BaseBuilder 公开，但随后我们会遇到另一个矛盾的陈述：

• 我们有一个不可实例化的类（抽象）
• 我们为它提供了一个公共构建器

因此，在 protected static 和 public abstract class 的构建器这两种情况下，我们结合了相互矛盾的陈述。这是个人喜好问题。

但是，我仍然更喜欢 abstract class 的 public 构建器，因为 protected static 在 OOD 和 OOP 世界中对我来说感觉更不自然！