Reglas a seguir para redefinir/implementar un método
Artículo por Club Developers · 15 mayo 2006
3312 vistas
Cuando redefinimos un método de una clase padre, o cuando implementamos un método de una interfaz, tenemos que conservar la definición exacta del método original: es el contrato que tenemos que respectar. No obstante, no es algo obligatorio y es posible modificar ciertos elementos.
Veamos un ejemplo y sus posibles modificaciones:
Definición del método original:
Con esta definición, es posible modificar los elementos siguientes:
1) El alcance/visibilidad del método:
Podemos cambiar la visibilidad del método, con la condición de aumentarla. Por lo tanto, un método protected puede pasar a ser public, lo mismo que un método son modificador (visibilidad limitada al paquete) podrá pasar a ser protected o public.
Esto es posible devido a que la definición del método original se conserva (sigue teniendo, como mÃnimo, la visibilidad original).
El caso inverso (quitar visibilidad) no esposible.
De esta manera, el método definido a continuación es correcto:
2) Las excepciones devueltas:
Es posible modificar la declaración de las excepciones devueltas por un método mientra que respetemos las del método padre.
AsÃ, podremos hacer:
En nuestro ejemplo, los dos métodos siguientes son correctos (porque FileNotFoundException y ZipException heredados de IOException) :
Borrado de la excepción:
Especialización de la excepción:
3) Cambio del tipo devuelto (Java 5.0):
La versión 5.0 de Java aporta una nueva posibilidad: poder modificar el tipo devuelto por el método. No obstante, es necesario que el nuevo tipo herede del tipo devuelto por el padre.
De esta manera, en nuestro ejemplo, podemos hacer que el método devuelva un Long (devido a que Long hereda de Number):
Total, que podemos llegar a tener métodos muy diferentes de los originales si se hace una redefinición de forma correcta.
Veamos algunos ejemplos:
Por otra parte, puede que sea difÃcil detectar que un método redefine otro con tanta modificación. En estos casos es aconsejable usar el tag javadoc @Override (a partir de Java 5.0).
Veamos un ejemplo y sus posibles modificaciones:
Definición del método original:
java
Con esta definición, es posible modificar los elementos siguientes:
1) El alcance/visibilidad del método:
Podemos cambiar la visibilidad del método, con la condición de aumentarla. Por lo tanto, un método protected puede pasar a ser public, lo mismo que un método son modificador (visibilidad limitada al paquete) podrá pasar a ser protected o public.
Esto es posible devido a que la definición del método original se conserva (sigue teniendo, como mÃnimo, la visibilidad original).
El caso inverso (quitar visibilidad) no esposible.
De esta manera, el método definido a continuación es correcto:
java
2) Las excepciones devueltas:
Es posible modificar la declaración de las excepciones devueltas por un método mientra que respetemos las del método padre.
AsÃ, podremos hacer:
- Borrar la excepción: efectivamente, no devolviendo ninguna excepción respetamos la declaración original devido a que throw significa "el método puede devolver una excepción", pero no es ninguna obligación
- Especializar el tipo de la excepción: indicando por ejemplo una excepción que herede de la definida en la declaración del método padre
En nuestro ejemplo, los dos métodos siguientes son correctos (porque FileNotFoundException y ZipException heredados de IOException) :
Borrado de la excepción:
java
Especialización de la excepción:
java
3) Cambio del tipo devuelto (Java 5.0):
La versión 5.0 de Java aporta una nueva posibilidad: poder modificar el tipo devuelto por el método. No obstante, es necesario que el nuevo tipo herede del tipo devuelto por el padre.
De esta manera, en nuestro ejemplo, podemos hacer que el método devuelva un Long (devido a que Long hereda de Number):
java
Total, que podemos llegar a tener métodos muy diferentes de los originales si se hace una redefinición de forma correcta.
Veamos algunos ejemplos:
java
etc...
Por otra parte, puede que sea difÃcil detectar que un método redefine otro con tanta modificación. En estos casos es aconsejable usar el tag javadoc @Override (a partir de Java 5.0).