2011-10-04 14 views
9

Como programador principiante de Java (pedante) me gustaría saber si es una buena práctica mover un bloque de código común que todas las subclases usan por separado protegido (final) método en la clase principal? Tareas como llenar listas con valores comunes, o algoritmos de filtrado comunes, etc ... ¿Es bueno usar también métodos estáticos protegidos?Utilizando métodos "protegidos finales" de superclase para mantener el código común para las subclases

class A { 
    protected final List<String> getVariants() {...} 
    protected final List<String> filterResults(List<String> variants) {...} 
} 

class B extends A { 
    public List<String> doSomethingUsefull() { 
     List<String> commonVariants = getVariants(); 
     ... 
     return filterResults(commonVariants); 
    } 
} 

class C extends A { 
    public void doSomethingUsefull() { 
     List<String> commonVariants = getVariants(); 
     ... 
     return filterResults(commonVariants); 
    } 

    public void doMoreUsefullThings() { 
     List<String> commonVariants = getVariants(); 
     ... 
     return filterResults(commonVariants); 
    } 
} 

Respuesta

19

Si es un principiante de Java y está pensando en este tipo de cosas, ahora es un buen momento para leer el Capítulo 4 "Clases e interfaces" en un libro llamado "Java eficaz". La información allí será más completa y matizada que las respuestas que obtienes aquí.

Aquí es una manera de pensar acerca de la mezcla de los final, protected y static palabras clave:

  • puristas OO le aconsejará para evitar static porque rompe el paradigma orientado a objetos.
  • Por supuesto, el uso de la palabra clave final evita que las subclases anulen un método también. A este respecto, el resultado es el mismo que con static.
  • final se debe utilizar con más frecuencia, y es una buena idea usarlo junto con protected. Consulte el elemento 17 en "Java efectivo".
  • protected y static no se utilizan juntos muy a menudo. Estarías mezclando una construcción OO con una construcción que rompe el comportamiento normal de OO, por lo que la combinación es impar.
+2

leyéndolo ahora. – dmzkrsk

+0

estático no es tan malo ... Bloch recomienda su uso para fabricar fábricas, por ejemplo. Y, por supuesto, no queremos que Math.floor() requiera una instancia de Matemáticas. Puede ser útil, pero se usa con cuidado, por supuesto. – PhiLho

+2

Estoy de acuerdo, pero una vez un purista trató de convencerme de todo lo contrario: ¡que los métodos 'Math' NO deberían ser estáticos! – jtoberon

4

Parece razonable para mí - aunque es posible que desee hacer A abstracta también. Considere también el uso de la composición en su lugar. ¿Podría B y Ccontener un A en lugar de crear una subclase?

+1

Composición sobre la herencia! Mucho más fácil de probar, +1 – Guillaume

+0

Parece que puede funcionar bastante bien en mi caso. ¡Voy a intentar eso! – dmzkrsk

0

Propongo mover todos estos métodos para separar la clase estática si no dependen de algunos campos de clase. Hacerlos métodos de utilidad.

2

En primer lugar, no debe utilizar se extiende a este propósito, porque extender demasiado siempre es una mala idea.

En segundo lugar, tiene toda la razón en que no repite su código, pero agruparlo por parte repetida del código no es una buena opción. La forma preferible es agrupar las cosas en el mundo real, por nivel de abstracción.

Por último, pero no menos importante, cuando tenga dudas: por separado o no, extensión o composición, protección final o solo protegida, pruebe la prueba de unidad de escritura para esta clase y las respuestas llegarán muy rápido.

Cuestiones relacionadas