Variable con el mismo nombre en la subclase y superclase

npkllr:

Actualmente estoy trabajando en algunas cuestiones FindBugs de otro proyecto de personas.
Este es el tema que estoy trabajando en:

Corrección - Clase campo que define un campo máscaras superclase
Esta clase define un campo con el mismo nombre que un campo de instancia visible en una superclase. Esto es confuso, y puede indicar un error si la actualización métodos de acceso o uno de los campos cuando querían la otra.

No es la superclase OutputInterfacey la subclase CoreOutputInterfaceque se extiende OutputInterface. Ambos definen la variable className. CoreOutputInterfacetiene algunas subclases también.

Para solucionar el problema yo simplemente retire el classNamede la subclase ( CoreOutputInterface) ya que ya está definido en la superclase.
La variable no se lee o set con super.classNameo this.className, sólo que con className, por lo que en mi opinión no debe dar lugar a ningún problema.
También la variable de la superclase no se hace referencia en todo el proyecto (lo he comprobado con la función de referencia Eclipse).

Alguien puede confirmar que esto no puede conducir a un problema en cualquier situación?

Gracias de antemano por tu ayuda.

---

OutputInterface:

public abstract class OutputInterface {

    protected String className = null;

    ...
}

CoreOutputInterface:

public abstract class CoreOutputInterface extends OutputInterface {

    protected String className = null;

    ...

    public void getClassName() {
        return className;
    }

    public void setClassName(String newName) {
        className = newName;
    }

    ...
}

dim8:

Sí, eliminar la declaración de la subclase. Y proporcionar / permiso como lo son en el ejemplo anterior un captador y, si es necesario, un regulador. Si nunca ha utilizado el campo, simplemente puede haber sido pasado por alto, cuando se creó 'CoreOutputInterface', como el desarrollador podría tener copia-pegar 'OutputInterface' y luego editado en consecuencia.

Más en teoría, esto es, o podría llegar a ser, dependiendo de la complejidad y el uso de la clase, un ejemplo de roto principio de sustitución Liskov de los conocidos SÓLIDO principios de diseño de programación orientada a objetos. Se afirma que los objetos de la superclase debe ser en todo momento reemplazable con sus homólogos de las subclases. Dado que hay una diferencia entre ambos campos '' className en uso, un método podría falsamente depender de uno o el otro y dar lugar a un comportamiento indefinido, como se indica en el informe.

Sin embargo, estoy más confundido, ¿por qué una 'clase' se denomina una interfaz .

• Si era realmente una interfaz, no habríamos tenido el problema, en primer lugar, como interfaces sólo permiten constantes. En ese caso getter y setter habría sido suficiente.
• Si es realmente una clase, entonces uno debe caer el "interfaz" del nombre. De lo contrario, el nombre defectuosa solamente dificulta la comprensión y podría conducir a efectos secundarios inesperados en el futuro.