Por que no deberíamos usar estática protegida en java

Estaba pasando por esta pregunta ¿Hay alguna forma de anular las variables de clase en Java? El primer comentario con 36 votos a favor fue:

Si alguna vez ve un protected static, ejecute.

¿Alguien puede explicar por qué está protected staticmal visto?

Es más una cuestión de estilo que un problema directo. Sugiere que no ha pensado adecuadamente en lo que está sucediendo con la clase.

Pensar en qué static significa:

Esta variable existe a nivel de clase, no existe por separado para cada instancia y no tiene una existencia independiente en las clases que me extienden .

Pensar en qué protected significa:

Esta variable puede ser vista por esta clase, clases en el mismo paquete y clases que me extienden .

Los dos significados no son exactamente excluyentes entre sí, pero están bastante cerca.

El único caso que puedo ver en el que podría usar los dos juntos es si tuviera una clase abstracta que fue diseñada para ser extendida y la clase extensible podría modificar el comportamiento usando constantes definidas en el original. Sin embargo, ese tipo de arreglo probablemente terminaría muy desordenado e indica una debilidad en el diseño de las clases.

En la mayoría de los casos, sería mejor tener las constantes como públicas, ya que eso solo hace que todo sea más limpio y permite a las personas que subclasifican más flexibilidad. Aparte de cualquier otra cosa, en muchos casos la composición es preferible a la herencia, mientras que las clases abstractas fuerzan la herencia.

Para ver un ejemplo de cómo esto podría romper las cosas y para ilustrar lo que quiero decir con la variable que no tiene una existencia independiente, pruebe este código de ejemplo:

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

Verás los resultados:

test
changed

Pruébelo usted mismo en: https://ideone.com/KM8u8O

La clase Test2puede acceder al miembro estático testdesde Testsin necesidad de calificar el nombre, pero no hereda ni obtiene su propia copia. Está mirando exactamente el mismo objeto en la memoria.

Está mal visto porque es contradictorio.

Hacer una variable protectedimplica que se usará dentro del paquete o se heredará dentro de una subclase .

Hacer la variable la staticconvierte en miembro de la clase, eliminando las intenciones de heredarla . Esto deja solo la intención de ser utilizado dentro de un paquete , y tenemos package-privatepara eso (sin modificador).

La única situación para la que podría encontrar esto útil es si estuviera declarando una clase que debería usarse para iniciar la aplicación (como JavaFX Application#launch, y solo quisiera poder iniciar desde una subclase. Si lo hace, asegúrese de que el método también sea finalpara no permitir la ocultación . Pero esto no es "la norma", y probablemente se implementó para evitar agregar más complejidad al agregar una nueva forma de iniciar aplicaciones.

Para ver los niveles de acceso de cada modificador, vea esto: Los tutoriales de Java: control del acceso a los miembros de una clase

No veo una razón en particular por la que esto deba estar mal visto. Siempre puede haber alternativas para lograr el mismo comportamiento, y dependerá de la arquitectura real si estas alternativas son "mejores" que un método estático protegido o no. Pero un ejemplo en el que un método estático protegido sería razonable, al menos, podría ser el siguiente:

(Editado para dividir en paquetes separados, para hacer el uso protectedmás claro)

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

Derivado de eso:

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

Otra clase derivada:

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

El protected staticmodificador ciertamente se puede justificar aquí:

• Los métodos pueden serlo static, porque no dependen de variables de instancia. No están destinados a ser utilizados directamente como un método polimórfico, sino que son métodos de "utilidad" que ofrecen implementaciones predeterminadas. que son parte de un cálculo más complejo y sirven como "bloques de construcción" de la implementación real.
• Los métodos no deberían serlo public, porque son un detalle de implementación. Y no pueden ser privateporque deberían ser llamados por las clases extendidas. Tampoco pueden tener visibilidad "predeterminada", porque entonces no serán accesibles para las clases extendidas en otros paquetes.

(EDITAR: Se podría suponer que el comentario original solo se refería a campos , y no a métodos ; entonces, sin embargo, era demasiado general)

Los miembros estáticos no se heredan y los miembros protegidos solo son visibles para las subclases (y, por supuesto, la clase que los contiene), por lo que a protected statictiene la misma visibilidad que static, lo que sugiere un malentendido por parte del codificador.

En realidad, no hay nada fundamentalmente malo en ello protected static. Si realmente desea una variable o método estático que sea visible para el paquete y todas las subclases de la clase declarante, entonces hágaloprotected static .

Algunas personas generalmente evitan el uso protectedpor varias razones y algunas personas piensan que las staticvariables no finales deben evitarse por todos los medios (personalmente simpatizo con esta última hasta cierto punto), por lo que supongo que la combinación de protectedy staticdebe quedar mal ^ 2 con las que pertenecen a ambos grupos.

Protegido se usa para que pueda usarse en subclases. No hay lógica en definir una estática protegida cuando se usa en el contexto de clases concretas, ya que se puede acceder a la misma variable de forma estática, sin embargo, el compilador dará una advertencia para acceder a la variable estática de la superclase de forma estática.

Bueno, como la mayoría de la gente ha respondido:

• protectedsignifica - ' paquete-privado + visibilidad a subclases - la propiedad / comportamiento es HEREDADA '
• staticsignifica - ' lo opuesto a la instancia - es una propiedad / comportamiento de CLASE, es decir, NO ES HEREDADO '

Por tanto, son levemente contradictorios e incompatibles.

Sin embargo, recientemente se me ocurrió un caso de uso en el que podría tener sentido usar estos dos juntos. Imagine que desea crear una abstractclase que sea padre para tipos inmutables y que tenga un montón de propiedades que son comunes a los subtipos. Para implementar la inmutabilidad correctamente y mantener la legibilidad, uno podría decidir usar el patrón 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;
    }
}

Y por qué protected static? Porque quiero un subtipo no abstracto AbstactTypeque implemente su propio Builder no abstracto y esté ubicado afuera package Xpara poder acceder y reutilizar el 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;
    }
}

Por supuesto que podemos hacer BaseBuilderpúblico pero luego llegamos a otras declaraciones contradictorias:

• Tenemos una clase no instanciable (resumen)
• Proporcionamos un constructor público para ello.

Entonces, en ambos casos con protected staticy publicconstructor de unabstract class combinamos declaraciones contradictorias. Es una cuestión de preferencias personales.

Sin embargo, sigo prefiriendo el publicconstructor de unabstract class porque protected staticme parece más antinatural en un mundo OOD y OOP.

No hay nada de malo en tener protected static. Una cosa que mucha gente está pasando por alto es que es posible que desee escribir casos de prueba para métodos estáticos que no desea exponer en circunstancias normales. He notado que esto es particularmente útil para escribir pruebas para métodos estáticos en clases de utilidad.