modificadores - para que sirve static en java

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

Question

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

Si alguna vez ves una protected static , ejecuta.

¿Alguien puede explicar por qué una protected static mal vista?

Answer 1

En realidad, no hay nada fundamentalmente malo con la protected static . Si realmente quiere una variable estática o un método que sea visible para el paquete y todas las subclases de la clase declarante, proceda y establezca la protected static .

Algunas personas generalmente evitan usar protected por varias razones y algunas personas piensan que las variables static no finales deben evitarse por todos los medios (personalmente simpatizo con este último hasta cierto punto), así que supongo que la combinación de protected y static debe verse mal ^ 2 a los que pertenecen a ambos grupos.

Answer 2

Es más una cosa estilística que un problema directo. Sugiere que no ha pensado bien qué está pasando con la clase.

Piensa en lo que significa static :

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 .

Piensa en lo que significa protected :

Esta variable se puede ver en esta clase, las clases en el mismo paquete y las clases que me extienden .

Los dos significados no son exactamente mutuamente excluyentes, pero es bastante cercano.

El único caso en el que puedo ver dónde puede usar los dos juntos es si tiene una clase abstracta que se diseñó para extenderse y la clase que se extiende podría modificar el comportamiento utilizando las constantes definidas en el original. Incluso entonces es una razón muy débil, ya que de todos modos sería mejor tener las constantes como públicas. Eso solo hace que todo sea más limpio y permite que las personas subclasifiquen más flexibilidad.

Para expandir y explicar el primer punto, prueba 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 Test2 puede acceder a la test miembros estáticos de Test sin necesidad de calificar el nombre, pero no hereda ni obtiene su propia copia. Está buscando exactamente la misma variable.

Answer 3

Está mal visto porque es contradictorio.

Hacer que una variable esté protected implica que se usará dentro del paquete o se heredará dentro de una subclase .

Hacer que la variable sea static convierte en miembro de la clase, eliminando las intenciones de heredarlo . Esto solo deja la intención de ser utilizado dentro de un paquete , y tenemos package-private para eso (sin modificador).

La única situación en la que podría encontrar esto útil es si estaba declarando una clase que debería usarse para iniciar la aplicación (como el Application#launch de Application#launch JavaFX, y solo quería poder iniciar desde una subclase. Si lo hace, asegúrese de que el método también es final para prohibir el hiding . 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, consulte esto: Tutoriales de Java: control del acceso a los miembros de una clase

Answer 4

Los miembros estáticos no son heredados, y los miembros protegidos solo son visibles para las subclases (y, por supuesto, la clase contenedora), por lo que una protected static tiene la misma visibilidad que la static , lo que sugiere un malentendido por parte del codificador.

Answer 5

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. Me di cuenta de que esto es particularmente útil para escribir pruebas para el método estático en las clases de utilidad.

Answer 6

No veo una razón particular por la que esto deba ser 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 donde 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 de protected má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 modificador protected static ciertamente se puede justificar aquí:

• Los métodos pueden ser static , ya que 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 "componentes básicos" de la implementación real.
• Los métodos no deben ser public , porque son un detalle de implementación. Y no pueden ser private porque deben ser llamados por las clases que se extienden. Tampoco pueden tener visibilidad "predeterminada", porque entonces no serán accesibles para las clases que se extienden en otros paquetes.

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

Answer 7

Protected se usa para que se pueda usar en subclases. No existe una lógica para definir una estática protegida cuando se usa en el contexto de clases concretas, ya que 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 una manera estática.