java - especificadores - modificadores de acceso poo

Modificador de acceso de constructor de clase abstracta

Question

Una clase abstracta solo puede usarse como una clase base que se extiende por alguna otra clase, ¿verdad? El constructor (es) de una clase abstracta puede tener los modificadores de acceso habituales (públicos, protegidos y privados (para uso interno)). ¿Cuál de los protected y public es el modificador de acceso correcto para usar, ya que el tipo abstracto parece indicar que técnicamente un constructor público actuará de forma muy protegida? ¿Debería usar protected en todos mis constructores?

Answer 1

ya que el tipo abstracto parece indicar que técnicamente un constructor público actuará de forma muy protegida

Esto no es correcto. Una clase abstracta no se puede instaurar directamente llamando a su constructor; sin embargo, cualquier implementación concreta heredará los métodos y la visibilidad de la clase abstracta.

Entonces, la clase abstracta ciertamente puede tener constructores públicos.

En realidad, el constructor de la clase abstracta solo puede invocarse desde el constructor de la implementación, por lo que no hay diferencia entre que sea público o esté protegido. P.ej:

public class Scratch
{
public static abstract class A
{
public A( int i ) {}
}
public static class B extends A
{
private B() { super(0); };
}
}

Answer 2

ya que el tipo abstracto parece indicar que técnicamente un constructor público actuará de forma muy protegida

Umm ... para las clases abstractas, este ámbito de constructor [público o protegido] no tiene mucha diferencia ya que la instanciación no está permitida [incluso si es pública]. Como debe ser invocado por la subclase, puede invocar a un constructor público o protegido sin problemas.

Está completamente en la elección de qué usar. Generalmente prefiero el público como lo es en la mayoría de los casos.

Answer 3

Por lo menos, una clase abstracta debe tener un constructor protegido. No es estrictamente necesario, ya que no es posible usar el constructor de todos modos, pero hace que el contrato sea explícito.

Otra opción es hacer que el constructor sea privado. Sin embargo, esta es solo una buena idea si todas las implementaciones de la clase son clases internas privadas. Un ejemplo raro pero útil.

Answer 4

Si este comportamiento es cierto, y no estoy seguro de que sea así, siempre debe usar el alcance más restringido disponible para que su aplicación funcione. Entonces, en ese caso, recomendaría usar protected.