Pourquoi nous ne devrions pas utiliser les statiques protégés en java

les éléments statiques ne sont pas hérités, et les éléments protégés ne sont visibles que pour les sous-classes (et bien sûr la classe contenant), de sorte qu'un protected static a la même visibilité que static , ce qui suggère un malentendu par le codeur.

Protégé est utilisé de sorte qu'il peut être utilisé dans des sous-classes. Il n'y a pas de logique dans la définition d'une statique protégée lorsque l'on utilise dans le contexte de classes concrètes car vous pouvez accéder à la même variable est une manière statique.Cependant, le complier donnera un avertissement pour accéder à la variable statique super class d'une manière statique.

en fait, il n'y a rien de fondamentalement mauvais avec protected static . Si vous voulez vraiment une variable statique ou une méthode qui est visible pour le paquet et toutes les sous-classes de la classe déclarante alors allez-y et faites protected static .

certaines personnes évitent généralement d'utiliser protected pour diverses raisons et certaines personnes pensent que les variables non-finales static devraient être évitées par tous les moyens (je compatis personnellement à ces derniers dans une certaine mesure), donc je suppose que le combinaison de protected et static doit regarder mauvais^2 que ceux qui appartiennent aux deux groupes.

il n'y a pas de mal à avoir protected static . Une chose que beaucoup de gens négligent est que vous pouvez vouloir écrire des cas de test pour les méthodes statiques que vous ne voulez pas exposer dans des circonstances normales. J'ai remarqué que c'est particulièrement utile pour écrire des tests pour la méthode statique dans les classes d'utilité.

eh Bien, comme la plupart des gens ont répondu:

• protected signifie - ' paquet-privé + visibilité vers les sous - classes-la propriété/le comportement est hérité '
• static signifie - le contraire de l'instance - il s'agit d'une propriété/comportement de classe, I. e il N'est pas hérité

par conséquent, ils sont légèrement contradictoires et incompatible.

Cependant, récemment, je suis venu à un cas d'utilisation où il pourrait être judicieux d'utiliser les deux ensemble. Imaginez que vous voulez créer une classe abstract qui est un parent pour les types immuable et il a un tas de propriétés qui sont communes aux sous-types. Pour mettre en œuvre immutabilité correctement et garder lisibilité on pourrait décider d'utiliser le Constructeur modèle.

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;
    }
}

et pourquoi protected static ? Parce que je veux qu'un sous-type non abstrait de AbstactType qui implémente son propre constructeur non abstrait et qui est situé à l'extérieur de package X puisse accéder et réutiliser le 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;
    }
}

bien sûr que nous pouvons rendre le BaseBuilder public mais alors nous arrivons à une autre déclarations contradictoires:

• Nous avons un non-instantiatable classe (abstraite)
• nous fournissons un constructeur public pour elle

donc dans les deux cas avec protected static et public constructeur d'un abstract class nous combinons des affirmations contradictoires. C'est une question de préférences personnelles.

Cependant, je préfère encore le public constructeur d'une abstract class parce que le protected static me semble plus contre-nature dans un monde OOD et OOP !