privada - ¿Cambiar el modificador de acceso de un método invalidado en Java?

modificadores de acceso java pdf

Question

¿Hay alguna razón por la que se pueda cambiar el modificador de acceso de un método anulado? Por ejemplo,

abstract class Foo{
void start(){...}
}

Y luego cambiar el modificador de acceso privado del paquete a public ,

final class Bar extends Foo{
@Override
public void start(){...}
}

Solo hago esta pregunta por curiosidad.

Answer 1

La explicación es esta:

Es un principio fundamental en OOP: la clase secundaria es una instancia completa de la clase principal y, por lo tanto, debe presentar al menos la misma interfaz que la clase principal. > Hacer que las cosas protegidas / públicas sean menos visibles violaría esta idea; podría hacer que las clases secundarias> sean inutilizables como instancias de la clase primaria.

 class Person{
public void display(){
//some operation
}
}
class Employee extends Person{
private void display(){
//some operation
}
Person p=new Employee();

Aquí p es la referencia de objeto con tipo Person (superclase), cuando llamamos> p.display () ya que el modificador de acceso es más restrictivo que la referencia de objeto p no puede acceder al objeto secundario de tipo Employee

Answer 2

Extender una clase significa que la subclase debería al menos ofrecer la misma funcionalidad a las otras clases.

Si él extiende eso, entonces no es un problema.

La extensión podría ser agregar nuevos métodos o ofrecer métodos existentes a más clases, como hacer público un método de acceso a paquetes.

Answer 3

Java no le permite hacer que el modificador de acceso sea más restrictivo , ya que eso violaría la regla de que una instancia de subclase debería ser utilizable en lugar de una instancia de superclase. Pero cuando se trata de hacer que el acceso sea menos restrictivo ... bueno, tal vez la superclase fue escrita por una persona diferente y no anticiparon la forma en que desea utilizar su clase.

Los programas que las personas escriben y las situaciones que surgen cuando la programación es tan variada, es mejor para los diseñadores de idiomas que no "cuestionen" qué es lo que los programadores quieren hacer con su idioma. Si no hay una buena razón para que un programador no pueda hacer que los especificadores de acceso sean menos restrictivos en una subclase (por ejemplo), entonces es mejor dejar esa decisión al programador. Saben los detalles específicos de su situación individual, pero el diseñador de idiomas no. Así que creo que esta fue una buena decisión de los diseñadores de Java.

Answer 4

Solo hay uno, es posible que desee que el reemplazo sea visible por más clases, ya que ningún modificador es el predeterminado, el público lo amplía.

Answer 5

Edit: OK, cambié mi respuesta para solucionar el problema.

Si eso no se pudiera hacer, entonces habría algunos casos en los que una clase no podría implementar una interfaz y extender una clase porque tienen el mismo método con diferentes modificadores de acceso.

public Interface A {
public void method();
}
public abstract classs B {
protected void method();
}
public class AB extends B implements A {
/*
* This would''t be possible if the access modifier coulnd''t be changed
* to less restrictive
*/
public void method();
}