Pourquoi nous ne devrions pas utiliser de statique protégé en Java

J'étais en train de passer en revue cette question. Existe-t-il un moyen de remplacer les variables de classe en Java? Le premier commentaire avec 36 votes positifs était:

Si jamais vous voyez un protected static, courez.

Quelqu'un peut-il expliquer pourquoi un est protected staticmal vu?

C'est plus un problème stylistique qu'un problème direct. Cela suggère que vous n'avez pas bien réfléchi à ce qui se passe avec la classe.

Pensez à ce que staticsignifie:

Cette variable existe au niveau de la classe, elle n'existe pas séparément pour chaque instance et elle n'a pas d'existence indépendante dans les classes qui me prolongent .

Pensez à ce que protectedsignifie:

Cette variable peut être vue par cette classe, les classes dans le même package et les classes qui me prolongent .

Les deux significations ne sont pas exactement mutuellement exclusives, mais elles sont assez proches.

Le seul cas que je peux voir où vous pourriez utiliser les deux ensemble est si vous aviez une classe abstraite qui a été conçue pour être étendue et que la classe d'extension pourrait alors modifier le comportement en utilisant les constantes définies dans l'original. Ce genre d'arrangement finirait probablement par être très compliqué et indique une faiblesse dans la conception des classes.

Dans la plupart des cas, il serait préférable que les constantes soient publiques, car cela rend tout plus propre et permet aux personnes de sous-classer plus de flexibilité. Indépendamment de toute autre chose, dans de nombreux cas, la composition est préférable à l'héritage, tandis que les classes abstraites forcent l'héritage.

Pour voir un exemple de la façon dont cela pourrait casser les choses et pour illustrer ce que je veux dire par la variable n'ayant pas d'existence indépendante, essayez cet exemple de code:

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

Vous verrez les résultats:

test
changed

Essayez-le vous-même sur: https://ideone.com/KM8u8O

La classe Test2peut accéder au membre statique à testpartir de Testsans avoir besoin de qualifier le nom - mais elle n'hérite ni n'obtient sa propre copie. Il regarde exactement le même objet en mémoire.

C'est mal vu parce que c'est contradictoire.

La création d'une variable protectedimplique qu'elle sera utilisée dans le package ou qu'elle sera héritée dans une sous-classe .

Faire de la variable en staticfait un membre de la classe, éliminant les intentions d'en hériter . Cela ne laisse que l'intention d'être utilisé dans un package , et nous avons package-privatepour cela (pas de modificateur).

La seule situation pour laquelle je pourrais trouver cela utile est si vous déclariez une classe qui devrait être utilisée pour lancer l'application (comme celle de JavaFX Application#launch, et que vous vouliez uniquement pouvoir lancer à partir d'une sous-classe. Si vous le faites, assurez-vous que la méthode est également finalà disallow cacher . Mais ce n'est pas « la norme », et a probablement été mis en œuvre pour empêcher l' ajout d'une plus grande complexité en ajoutant une nouvelle façon de lancer des applications.

Pour voir les niveaux d'accès de chaque modificateur, voir ceci: Les didacticiels Java - Contrôle de l'accès aux membres d'une classe

Je ne vois pas de raison particulière pour laquelle cela devrait être mal vu. Il peut toujours y avoir des alternatives pour obtenir le même comportement, et cela dépendra de l'architecture réelle si ces alternatives sont "meilleures" qu'une méthode statique protégée ou non. Mais un exemple où une méthode statique protégée serait raisonnable, au moins, pourrait être le suivant:

(Modifié pour être divisé en packages séparés, pour rendre l'utilisation de protectedplus claire)

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

Dérivé de cela:

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

Une autre classe dérivée:

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

Le protected staticmodificateur peut certainement être justifié ici:

• Les méthodes peuvent l'être static, car elles ne dépendent pas des variables d'instance. Ils ne sont pas destinés à être utilisés directement comme une méthode polymorphe, mais sont plutôt des méthodes «utilitaires» qui offrent des implémentations par défaut qui font partie d'un calcul plus complexe et servent de «blocs de construction» de l'implémentation réelle.
• Les méthodes ne devraient pas l'être public, car elles sont un détail d'implémentation. Et ils ne peuvent pas l'être privatecar ils devraient être appelés par les classes étendues. Ils ne peuvent pas non plus avoir de visibilité "par défaut", car ils ne seront alors pas accessibles pour les classes d'extension dans d'autres packages.

(EDIT: on pourrait supposer que le commentaire original ne faisait référence qu'à des champs , et non à des méthodes - alors, cependant, c'était trop général)

Les membres statiques ne sont pas hérités, et les membres protégés ne sont visibles que par les sous-classes (et bien sûr la classe contenant), donc a protected statica la même visibilité que static, suggérant un malentendu de la part du codeur.

En fait, il n'y a rien de fondamentalement mal avec protected static. Si vous voulez vraiment une variable statique ou une méthode visible pour le package et toutes les sous-classes de la classe déclarante, allez-y et créez-la protected static.

Certaines personnes évitent généralement d'utiliser protectedpour diverses raisons et certaines personnes pensent que les staticvariables non finales devraient être évitées par tous les moyens (je sympathise personnellement avec ces dernières dans une certaine mesure), donc je suppose que la combinaison de protectedet staticdoit paraître mauvaise ^ 2 à ceux qui appartiennent aux deux groupes.

Protected est utilisé pour pouvoir être utilisé dans les sous-classes. Il n'y a pas de logique dans la définition d'une statique protégée lors de l'utilisation dans le contexte de classes concrètes car vous pouvez accéder à la même variable de manière statique.Cependant, le complicateur donnera un avertissement pour accéder à la variable statique de la super classe de manière statique.

Eh bien, comme la plupart des gens ont répondu:

• protectedsignifie - ' package-private + visibilité aux sous-classes - la propriété / le comportement est HÉRITÉ '
• staticsignifie - ' l'opposé de l'instance - c'est une propriété / un comportement de CLASSE, c'est-à-dire qu'elle n'est PAS HÉRITÉE '

Par conséquent, ils sont légèrement contradictoires et incompatibles.

Cependant, récemment, je suis venu à un cas d'utilisation où il pourrait être judicieux d'utiliser ces deux ensemble. Imaginez que vous vouliez créer une abstractclasse qui est un parent pour les types immuables et qui a un tas de propriétés qui sont communes aux sous-types. Pour implémenter correctement l' immuabilité et conserver la lisibilité, vous pouvez décider d'utiliser le modèle 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;
    }
}

Et pourquoi protected static? Parce que je veux un sous-type non abstrait AbstactTypequi implémente son propre constructeur non abstrait et est situé à l'extérieur package Xpour pouvoir 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, nous pouvons rendre le BaseBuilderpublic mais ensuite nous arrivons à une autre déclaration contradictoire:

• Nous avons une classe non instanciatable (abstraite)
• Nous fournissons un constructeur public pour cela

Donc, dans les deux cas avec protected staticet publicconstructeur d'un,abstract class nous combinons des déclarations contradictoires. C'est une question de préférences personnelles.

Cependant, je préfère toujours le publicconstructeur d'unabstract class car cela protected staticme semble plus artificiel dans un monde OOD et OOP!

Il n'y a rien de mal à avoir protected static. Une chose que beaucoup de gens oublient est que vous voudrez peut-être écrire des cas de test pour des méthodes statiques que vous ne voulez pas exposer dans des circonstances normales. J'ai remarqué que cela est particulièrement utile pour écrire des tests de méthode statique dans des classes utilitaires.