Java Override y encapsulación

El concepto de Java Override o overriding es uno de los conceptos que cuesta más entender cuando una comienza a trabajar con programación orientada a objeto. ¿Para que sirve el overriding o polimorfismo dinámico? . En Java en muchas ocasiones nos encontramos con situaciones en las cuales tenemos una jerarquía de clases en la que existe diferencia en cuanto a la implementación de alguno de sus métodos comunes. Vamos a usar un ejemplo basado en el concepto de Facturas.  Supongamos que disponemos de dos tipos de Facturas. Facturas con IVA y Facturas sin IVA. Ambas tienen como clase padre la clase Factura.

java override

Vamos a ver estas clases implementadas en código:


package com.arquitecturajava;

public abstract class Factura {

private String id;
 private double importe;
 public String getId() {
 return id;
 }
 public void setId(String id) {
 this.id = id;
 }
 public double getImporte() {
 return importe;
 }
 public void setImporte(double importe) {
 this.importe = importe;
 }
 public abstract double calcularTotal();
}


package com.arquitecturajava;

public class FacturaConIva extends Factura{

@Override
 public double calcularTotal() {
 return this.getImporte()*1.21;
 
 }

}


package com.arquitecturajava;

public class FacturaSinIva extends Factura{

@Override
 public double calcularTotal() {
 return this.getImporte();
 
 }

}

En este caso la implementación es muy sencilla , el método calcularImporte nos devuelve el importe total. Si la factura es con IVA sera un 21% más cara que si no lo es, así de sencillo. Vamos a ver el programa principal:


package com.arquitecturajava;

public class Principal {

 public static void main(String[] args) {
 
 
 FacturaConIva f1= new FacturaConIva();
 f1.setId("1");
 f1.setImporte(100);

 
 FacturaSinIva f2= new FacturaSinIva();
 f2.setId("2");
 f2.setImporte(100);
 
 System.out.println(f1.calcularTotal());
 System.out.println(f2.calcularTotal());
 }

}

Si lo ejecutamos veremos como una Factura se imprime incluyendo el IVA y la otra Factura se imprime con el coste actual.

java override resultado

Java Override

Acabamos de usar un Java Override la forma correcta sobrecargando los métodos de calcular importe. Sin embargo a mucha gente le cuesta entender que esto sea útil. Vamos a modificar el programa para realizar la misma operación de una forma un poco diferente.


 

package com.arquitecturajava;

public class Principal {

public static void main(String[] args) {


FacturaConIva f1= new FacturaConIva();
f1.setId("1");
f1.setImporte(100);
FacturaSinIva f2= new FacturaSinIva();
f2.setId("2");
f2.setImporte(100);

imprimirImporte(f1);
imprimirImporte(f2);
}

public static void imprimirImporte(Factura f) {

System.out.println(f.calcularTotal());
}

}

El código parece muy similar  de hecho el resultado por consola  es idéntico. Ahora bien gracias al polimorfísmo la persona que programa el método imprimirImporte no tiene necesidad de conocer la jerarquía de clases Factura. Le es suficiente con conocer el concepto de Factura.

java override encapsulacion

 

El polimorfismo nos ayuda a encapsular conceptos y reducir los que tenemos que conocer simplificando los programas. Esta es una de sus  grandes ventajas.

Otros artículos relacionados: Java this vs this() , Java Constructores this() y super() , Java interface y extensibilidad

 

About Cecilio Álvarez Caules

Cecilio Álvarez Caules Sun Certified Enterprise Architech (J2EE/JEE).

3 Responses to Java Override y encapsulación

  1. elhornillo 16 noviembre, 2016 at 16:16 #

    @Override también nos ayuda a detectar los métodos “sobreescritos” cuando éstos cambian.

    Si el método calcularTotal no fuera abstracto, y se cambia agregando un parámetro (paisFiscal) el propio compilador nos diría que las clases FacturaSinIva y FacturaConIva están sobreescribiendo algo que no existe. Esto en plataforma donde hay muchas implementaciones de “algo” te ayuda a su mantenimiento y a detectar rápidamente el impacto.

    • Cecilio Álvarez Caules 16 noviembre, 2016 at 17:21 #

      Tienes razón hubiera quedado mejor implementando la clase abstracta con un método por defecto , a ver si saco un rato y lo modifico , gracias por el aporte 🙂

    • Toni 15 febrero, 2017 at 13:50 #

      Aunque el método sea abstracto, si cambiamos su firma, el compilador también nos avisa de los mètodos que lo sobreescriben (ahora incorrectamente).

      De echo creo que es mejor que sea abstracto porque en la classe Factura todavia no sabemos que implementación tendrà éste método.

      Saludos.

Deja un comentario