Javaで保護されたstaticを使用してはならない理由

私はこの質問を通過しましたJavaでクラス変数をオーバーライドする方法はありますか？ 36の賛成票を持つ最初のコメントは次のとおりです。

が表示された場合はprotected static、実行してください。

誰がなぜprotected static眉をひそめているのか説明できますか？

それは直接的な問題というよりは文体的なものです。それはあなたがクラスで何が起こっているのかを適切に考えていなかったことを示唆しています。

static意味を考えてみてください。

この変数はクラスレベルに存在し、インスタンスごとに個別に存在することはありません。また、私を拡張するクラスに独立して存在することもありません。

protected意味を考えてみてください。

この変数は、このクラス、同じパッケージ内のクラス、および私を拡張するクラスから見ることができます。

2つの意味は、相互に排他的ではありませんが、かなり近いです。

2つを一緒に使用できる唯一のケースは、拡張するように設計された抽象クラスがあり、拡張クラスが元のクラスで定義された定数を使用して動作を変更できる場合です。このような配置は、おそらく非常に厄介なものになり、クラスの設計の弱点を示しています。

ほとんどの場合、定数をpublicにすると、すべてがよりクリーンになり、サブクラス化の柔軟性が向上するため、より適切です。抽象クラスは継承を強制しますが、多くの場合、他のものとはかなり離れて構成が継承よりも望ましいです。

これがどのように物事を壊すことができるかの1つの例を見て、独立した存在を持たない変数によって私が何を意味するかを説明するには、次の例のコードを試してください。

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名前を修飾する必要なし-しかし、それは継承しないか、独自のコピーを取得します。メモリ内のまったく同じオブジェクトを調べています。

それは矛盾しているのでそれは眉をひそめています。

変数を作成するprotectedと、パッケージ内で使用されるか、サブクラス内で継承されることになります。

変数staticを作成すると、変数がクラスのメンバーになり、継承する意図がなくなります。これは、パッケージ内で使用する意図のみを残し、私たちはそれpackage-privateをします（修飾子はありません）。

あなたはJavaFXののようなアプリケーションを（起動するために使用されなければならないクラスを宣言した場合、私はこの便利を見つけることができる唯一の状況がありApplication#launch、そして唯一のサブクラスから起動できるようにしたかった。そうする場合は、この方法でもあることを確認finalします不許可隠れる。しかし、これは「当たり前」ではない、おそらく打ち上げアプリケーションへの新しい方法を追加することによって、より複雑にすることを防止するために実装されました。

各修飾子のアクセスレベルを確認するには、次を参照してください。Javaチュートリアル-クラスのメンバーへのアクセスの制御

これが眉をひそめられるべきである特定の理由を私は見ません。同じ動作を実現する代替手段は常に存在する可能性があり、これらの代替手段が保護された静的メソッドよりも「優れている」かどうかは、実際のアーキテクチャに依存します。しかし、保護された静的メソッドが妥当である1つの例は、少なくとも次のとおりです。

（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、拡張クラスによって呼び出されるべきなので、そうすることはできません。また、他のパッケージの拡張クラスからアクセスできないため、「デフォルト」の可視性を持つこともできません。

（編集：元のコメントはメソッドではなくフィールドのみを参照していたと想定できますが、それでは一般的すぎます）

静的メンバーは継承されず、保護されたメンバーはサブクラス（もちろん、それを含むクラス）にのみ表示されるため、protected staticはと同じようstaticに表示され、コーダーによる誤解を示唆しています。

実際、には根本的な問題はありませんprotected static。パッケージと宣言クラスのすべてのサブクラスに表示される静的変数またはメソッドが本当に必要な場合は、先に進んでそれを作成してくださいprotected static。

一部の人々は、一般的に使用を避けるprotected非最終考える様々な理由や何人かの人々のためにstatic、私はの組み合わせを推測するので、変数は、（私は個人的にある程度後者に同情）是非とも避けるべきであるprotectedとstatic見なければならない2 ^悪いことをしたものに両方のグループに属しています。

Protectedを使用して、サブクラスで使用できるようにします。具象クラスのコンテキストで使用する場合、同じ変数にアクセスできるので静的な方法で保護されたstaticを定義するロジックはありませんが、コンパイラーは静的な方法でスーパークラスの静的変数にアクセスするよう警告します。

まあ、ほとんどの人が答えたように：

• protectedつまり、「package-private +サブクラスへの可視性-プロパティ/動作は継承されます」
• static意味-「インスタンスの反対-クラスのプロパティ/動作です。つまり、継承されません」

したがって、それらは少し矛盾しており、互換性がありません。

しかし、最近、私はこれら2つを一緒に使用することが理にかなっているかもしれないユースケースを思いつきました。不変の型のabstract親であり、サブタイプに共通の一連のプロパティを持つクラスを作成するとします。不変性を適切に実装し、読みやすさを維持するために、ビルダーパターンを使用することができます。

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公開することはできますが、それから別の矛盾する声明に行きます。

• インスタンス化できないクラスがあります（抽象）
• パブリックビルダーを提供しています

したがって、with protected staticとのpublicビルダーのabstract class両方で、矛盾するステートメントを組み合わせます。それは個人的な好みの問題です。

ただし、OODとOOPの世界では不自然に感じるので、私はまだのpublicビルダーをabstract class好みprotected staticます！

持っていることに何の問題もありませんprotected static。多くの人が見落としていることの1つは、通常の状況では公開したくない静的メソッドのテストケースを記述したい場合があることです。これは、ユーティリティクラスで静的メソッドのテストを作成する場合に特に便利です。