java - sirve - ¿Hay buenas razones para un constructor público de una clase abstracta
implementacion de clases abstractas en java (4)
No es posible crear un objeto llamando directamente al constructor de una clase abstract . El constructor de una clase abstract solo puede invocarse desde una clase derivada. Por lo tanto, me parece que los constructores de una clase abstracta deben estar protected o paquetes privados (el último para los casos inusuales de restringir el uso de un constructor a clases derivadas dentro del paquete). Sin embargo, Java permite que el constructor de una clase abstract sea public .
¿Hay alguna circunstancia en la que sea útil declarar el constructor de una clase abstract como public , en lugar de protected o paquete privado?
Esto no es exactamente un duplicado de la pregunta " Modificador de acceso de constructor de clase abstracta ": claramente puede declarar que un constructor es public ; Quiero saber si alguna vez hay una buena razón para hacerlo. Me parece que no hay. Veo que C # tiene una peculiaridad similar .
La respuesta es la misma para java:
No hay razón para un constructor público para una clase abstracta. Asumo que la razón por la que el compilador no se queja es tan simple que simplemente no se tomó el tiempo para cubrir eso, ya que realmente no importa si es público o está protegido. ( source )
No puede llamar a un constructor de una clase abstracta de otra cosa que no sea una subclase directa.
Por lo tanto, agregar una regla especial para modificadores de acceso de constructores de clases abstractas no agregaría algo útil para el lenguaje.
Una cosa que se parece a una excepción de esta regla: si la clase abstracta solo define un constructor predeterminado, entonces la subclase no tiene que implementar un constructor: esto es legal:
public abstract class A {
public A() {}
}
public class B extends A {}
Entonces podemos crear una B llamando a la new B() , pero tenga en cuenta que todavía creamos una B y no una A Y, nuevamente, no importa si el constructor en A es público o protegido. Simplemente no debería ser privado, pero el compilador lo notará y se quejará ...
En realidad, invocamos un constructor público predeterminado "invisible" en B que hace una llamada simple super() ...
La visibilidad también influye en lo que se muestra en el javadoc (si se selecciona para excluir ciertos niveles de visibilidad). Como no importa lo contrario, podría ser un uso para un constructor público de una clase abstracta.
Si no proporciona ningún constructor, entonces el constructor predeterminado es público si la clase es pública. La opción más fácil sería permitir eso, en lugar de forzar constructores protegidos.
En ese sentido, la pregunta inversa puede aclarar: ¿por qué no forzaron a los constructores protegidos en clases abstractas? Porque los constructores públicos no cambiarán nada, por lo que tomaría tiempo y agregaría complejidad.
Llámame hereje, pero ... Veo al menos un uso para un constructor en una clase abstracta.
Es decir: especificar a qué se parecen los parámetros del constructor.
Especifique un constructor abstracto (lo que hace que la clase sea abstracta). Las clases derivadas deben implementar este constructor con su firma específica para perder el estado abstracto.
No veo otra manera de especificar las firmas de constructor obligatorias (ayúdame si lo haces).
Puede tener un constructor público si no define en un constructor en la subclase. ejemplo
abstract class Animal {
String name;
public void Animal(String name) {
this.name = name;
}
}
class Cat extends Animal{
public String sayMayName() {
return this.name;
}
}
myCat = new Cat("tester");
name = myCat.sayMyName();
si no se define un constructor se llamará al constructor de la clase padre, si no es público, no funcionará. Esto creo que se hace de forma más elegante con un patrón de fábrica, pero lo usé en la práctica en PHP y funciona bien.