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 Test2
puede acceder al miembro estático test
desde Test
sin necesidad de calificar el nombre, pero no hereda ni obtiene su propia copia. Está mirando exactamente el mismo objeto en la memoria.
final
. Un campo estático mutable compartido entre clases es definitivamente motivo de preocupación. Es probable que varias clases que actualizan un campo estático no sean confiables o fáciles de seguir, especialmente porque la presencia de cualquier campo o método protegido implica que la clase está destinada a ser extendida por clases en otros paquetes, posiblemente clases que no están bajo el control del autor de la clase que contiene el campo protegido.