Carlos Fontela

cfontela@fi.uba.ar

Definimos
Encapsulamiento: cada objeto es responsable
de responder a los mensajes que recibe, sin
que quien le enva el mensaje tenga que
saber cmo lo hace
Polimorfismo: capacidad de respuesta que
tienen distintos objetos de responder de
maneras diferentes a un mismo mensaje
Hay consecuencias

2c2015

Polimorfismo y refactorizacin

Polimorfismo en general
Los lenguajes de comprobacin esttica:
vinculacin tarda e interfaces
Refactorizacin
TDD completo

2c2015

Capacidad que tienen distintos objetos de

responder de maneras diferentes a un mismo
mensaje
celda >> contiene(7)
fila >> contiene(7)
cajaAhorro >> extraer(100)
cuentaCorriente >> extraer(100)

Distintos objetos responden de maneras

diferentes a la llegada de un mensaje,
basndose en la clase de la cual son
instancias
cajaAhorro extraer: 100.
cuentaCorriente extraer: 100.

var celdaLibre = {
contiene : function (valor) {
return false;
}
}
var celdaOcupada = {
contiene : function (valor) {
return (this.numero == valor);
}
}
Slo en JavaScript? Y en lenguajes con clases?

Ajedrez: cada tipo de pieza tiene un

comportamiento distinto
=> Implementacin obvia (?)
Coronacin: qu ocurre?
Posible interpretacin: un objeto cambia de clase
(su comportamiento vara luego de un cambio de
estado)
hay otros planteos: no es el mismo objeto

Quedmonos con el inicial: puede un objeto

cambiar su clase?

2c2015

Coronacin: estado = new Reina ( );

9

2c2015

Hemos encapsulado un mtodo

(movimientoLegal) en un objeto
Podemos tratar a los mtodos como objetos
En Smalltalk todo es un objeto
En C# hay delegados

Es lo mismo del polimorfismo extremo de

JavaScript?
Es una solucin tpica
Se lo conoce como el patrn de diseo State
Ya volveremos
10

2c2015

Se plantea que el polimorfismo funciona

porque la decisin del mtodo a invocar se
toma en tiempo de ejecucin y no antes
Tiene sentido en lenguajes de comprobacin
esttica
cajaAhorro.extraer(100);
cuentaCorriente.extraer(100);

En Java se da por defecto

Si no lo queremos, poner final al mtodo

En C++ y C# se declaran mtodos virtuales

Collection <Cuenta> cuentas = new ArrayList

<Cuenta> ( );
...
for (Cuenta c : cuentas)
c.extraer(100);
Compilador verifica que la clase de c tenga un
mtodo extraer
Tiene sentido en lenguajes de comprobacin
esttica

Por qu contraponemos el uso de if al

polimorfismo?
Para qu querramos polimorfismo sin
herencia?
Polimorfismo es sinnimo de vinculacin
tarda?

public void depositar(int monto) {

for (Notificable e : entidadesNotificar)

e.notificarDeposito(monto);
}

Qu quiere decir <<interface>>?

Como mecanismo necesario para el

polimorfismo sin herencia

18

2c2015

Son como clases

Abstractas
Con todos los mtodos abstractos
Sin atributos (sin estado)

Ejemplo
public interface Notificable {
/*public abstract*/ void notificarDeposito();
}

Pueden heredar de otras interfaces

public interface RecibeMails extends Notificable {
void enviarMail();
}
19

2c2015

Uso
public class OficialCuenta extends Empleado
implements Notificable {
...
}

Corolario
Si una clase declara implementar una interfaz y no
implementa (redefine) uno de sus mtodos es
abstracta

20

2c2015

Son grupos de mtodos sin implementar

Una clase puede implementar varias
Ojo con los conflictos de nombres

21

2c2015

Cada objeto puede tener muchas caras, segn

el tipo con el que se lo accede
Fecha f = new Fecha(20,6,1964);
Imprimible i = f;
Comparable c = f;
Serializable s = f;

Todos se refieren al mismo objeto

Pero lo ven distinto
Cada variable slo puede usar los mtodos de su
interfaz

Ojo: slo puedo instanciar clases!

22

2c2015

El tipo de la variable define la interfaz que

puedo usar
Fecha f = new Fecha(20,6,1964);
Imprimible i = f;
Comparable c = f;
i.imprimir();
c.compareTo(c2);
f.imprimir();
f.compareTo(f2);

23

2c2015

Visin de lenguaje
Una clase muy abstracta que se puede usar para
herencia mltiple

Visin desde el uso

Un tipo de datos que permite que ver a un mismo
objeto con distintos tipos
=> Cada tipo implica un comportamiento

24

2c2015

Para qu sirven las interfaces? (por ahora)

Por qu no hay interfaces en Smalltalk?

27

2c2015

Todo cdigo va empeorando su calidad con el

tiempo
=> entropa, degradacin

Refactorizaciones
Mejorar cdigo, hacindolo ms comprensible
Sin cambiar funcionalidad

28

2c2015

Refactoring
Mejorar el cdigo ya escrito
Cmo?
Modificar estructura interna
Sin modificar comportamiento observable

Ejemplos:
Eliminar cdigo duplicado
Introducir polimorfismo
29

2c2015

Mejorar cdigo, hacindolo ms comprensible

Para modificaciones
Para depuraciones
Para optimizaciones

Mantener alta la calidad del cdigo

Si no, se degrada

A la larga, aumenta la productividad

30

2c2015

Actitud constante
Consecuencia de revisiones de cdigo
Antes de modificar cdigo existente
Despus de incorporar funcionalidad
Antes de optimizar
Ojo: optimizar refactorizar

Durante depuraciones

31

2c2015

Riesgo alto
Mxima: Si funciona, no lo arregle

Un paso por vez

Pruebas automatizadas
Escribirlas antes de refactorizar
Y correrlas luego de cada pequeo cambio

32

2c2015

Bad smells in code (malos olores), los llama

Fowler
Son indicadores de que algo est mal, y se
solucionan con refactorizaciones
Hay catlogos
Smalltalk desde los inicios
Java: lenguaje habitual

33

2c2015

CajaAhorro >> extraer(monto)

if (monto <= 0)
throw new MontoInvalido();
if (monto > this.getSaldo())
throw new SaldoInsuficiente();
this.saldo -= monto;

CuentaCorriente >> extraer(monto)

if (monto <= 0)
throw new MontoInvalido();
if (monto > this.getSaldo() + this.descubierto)
throw new SaldoInsuficiente();
this.saldo -= monto;

Test-Driven Development =
Test-First +
Automatizacin +
Refactorizacin

Para qu refactorizamos?
Por qu no hacemos varias refactorizaciones
seguidas?
Qu relacin hay entre TDD y refactorizacin?

Polimorfismo = distintos comportamientos

para un mismo mensaje
Polimorfismo seguro y sin herencia:
interfaces
Manejar la entropa => refactorizacin

38

2c2015

Replace Conditional with Polymorphism

https://sourcemaking.com/refactoring/replac
e-conditional-with-polymorphism
Continuous Integration, de Martin Fowler
http://www.martinfowler.com/articles/conti
nuousIntegration.html

39

2c2015

Profundizacin
UML
Excepciones
Otros

Repaso pre-parcial
Parcial

40

2c2015