Técnicas de programación

Técnicas avanzadas de programación
. . . o como hacer software sin morir en el intento
José Luis Diaz
26 de junio de 2014
José Luis Diaz 26 de junio de 2014 1 / 80

Principios de diseño
Agenda
1 Principios de diseño
Ocultación de la información
Hacia los objetos
2 SOLID
Single responsibility principle
Open-closed principle
Liskov substitution principle
Interface segregation principle
Dependency inversion principle
3 Testing
Test First Development
Técnicas de testing
Dependencias

Principios de diseño Ocultación de la información
Agenda
Hacia los objetos
2 SOLID
3 Testing
Dependencias

Dise˜no
¿Por que dise˜nar?

Dise˜no
Incorporar nuevos requerimientos evitando que el dise˜no se degrade.

Dise˜no
Los cambios puedan incorporarse con el menor costo posible.

Diseño
Los cambios puedan incorporarse con el menor costo posible.
Hacer el caso común fácil, el caso complejo posible (Joshua Blosh
sobre los lenguajes)

Parnas
Una metodolog´ıa para componentizar (Parnas, David a principio de los ’70)

Parnas
Identiﬁcar potenciales componentes. Detectar desde los
requerimientos los que mas vayan a cambiar.

Parnas
Se contraen y expanden los requerimientos de estos componentes.

Parnas
Se contraen y expanden los requerimientos de estos componentes.
Aislar estos componentes y generar interfaces que toleren estos
cambios anticipados.

Principios de dise˜no Hacia los objetos
Agenda
Hacia los objetos
2 SOLID
3 Testing
Dependencias

Limitaciones
Limitaciones del diseño basado en ocultación de información.

Limitaciones
Incluir todos los metodos de la interfaz de un modulo correspondiente
como un par´ametro.

Limitaciones
Generar varios modulos iguales.

Limitaciones
Generar varios modulos iguales.
Poder tener varias implementaciones diferentes de un mismo modulo
y poder intercambiarlos.

SOLID
Agenda
Hacia los objetos
2 SOLID
3 Testing
Dependencias

SOLID Single responsibility principle
Agenda
Hacia los objetos
2 SOLID
3 Testing
Dependencias

Cada clase debe tener una ´unica responsabilidad, y que esta debe ser
completamente ocultada por la clase (o modulo).

Cada clase debe tener una única responsabilidad, y que esta debe ser
completamente ocultada por la clase (o modulo).
Este principio fue originalmente descripto como “cohesión”, la
relación funcional de los elementos de una clase.

¿Por qu´e es importante este principio?

Si una clase tiene m´as de una responsabilidad, entonces las
responsabilidades est´an acopladas.

Los cambios en una de las responsabilidades pueden alterar o inhibir
la capacidad de la clase para cumplir con las otras.

Los cambios en una de las responsabilidades pueden alterar o inhibir
la capacidad de la clase para cumplir con las otras.
Este tipo de acoplamiento conduce a dise˜nos fr´agiles que se rompen
de manera inesperada cuando las clases cambian.

Aplicación de
geometría
computacional
Aplicación gráfica
GUI
Rectángulo
+ dibujar()
+ area(): double

Aplicación de
geometría
computacional
Aplicación gráficaGUI
Rectángulo
+ dibujar()
RectánguloGeométrico
+ area(): double

SOLID Open-closed principle
Agenda
Hacia los objetos
2 SOLID
3 Testing
Dependencias

Primera ves enunciada por Ivar Jacobson y luego reexpresada por
Bertran Meyer en “Object Oriented Software Construction”:
“Las entidades de software (clases, modulos, funciones, etc). Deben
estar abiertas para extensión, pero cerradas para modificación”

Primera ves enunciada por Ivar Jacobson y luego reexpresada por
Bertran Meyer en “Object Oriented Software Construction”:
“Las entidades de software (clases, modulos, funciones, etc). Deben
estar abiertas para extensión, pero cerradas para modificación”
Esforzarse para hacer que cuando el codigo cambie, solo lugar en un
lugar.

1 class Cuadrado { public double lado; }
2 class Circle { public double radio; }
3
4 class GUI {
5 Object[] figuras;
6
7 public void refresh() {
8 for (Object figura: figuras) {
9 if (figura instanceof Cuadrado) {
0 dibujarCuadrado(((Cuadrado) figura).lado);
1 }
2 else if (figura instanceof Circle) {
3 dibujarCirculo(((Circle) figura).radio);
4 }
5 }
6 }
7
8 private void dibujarCirculo(double radio) {}
9 private void dibujarCuadrado(double lado) {}
0 }

1 interface Dibujable { public void dibujar(); }
2 class Cuadrado implements Dibujable { public double lado; }
3
4 class Circle implements Dibujable { public double radio; }
5
6 class GUI {
7 List<Dibujable> figuras;
8
9 public void refresh() {
0 for (Dibujable figura: figuras) {
1 figura.dibujar()
2 }
3 }
4
5 }

SOLID Liskov substitution principle
Agenda
Hacia los objetos
2 SOLID
3 Testing
Dependencias

Propiedad
Propiedad de sustitución: Si para cada objeto o1 de tipo S hay un objeto
o2 de tipo T tal que: para todo programa P que se define en términos de
T, el comportamiento de P no varia cuando o1 es sustituido por o2
entonces S es un subtipo de T.

Una clara violaci´on del principio:
1 void dibujar(Figura f) {
2 if (figura instanceof Cuadrado) {
3 dibujarCuadrado(((Cuadrado) figura).lado);
4 }
5 else if (figura instanceof Circle) {
6 dibujarCirculo(((Circle) figura).radio);
7 }
8 }

El array en Java es covariante
1 String[] strings = new String[1];
2 Object[] objects = strings;
3 objects[0] = 1; // WAT!
Las Listas son invariantes.
4 List<String> ys = new LinkedList<String>();
5 ys.add("zero"); ys.add("one");
6 List<Object> a = yy // Error compilando
7 String y = ys.iterator().next();

SOLID Interface segregation principle
Agenda
Hacia los objetos
2 SOLID
3 Testing
Dependencias

Propiedad
Ning´un cliente tiene que ser forzado a depender de metodos que no utiliza.

1 interface Door {
2 public void lock();
3 public void unlock();
4 public boolean isDoorOpen();
5 }
6
7 class Timer {
8 public void Regsiter(int timeout, TimerClient client) {}
9 }
0
1 interface TimerClient {
2 public void timeOut();
3 }

TimerClient
Door TimedDoor

Door
TimedDoor DoorTimerAdapter
TimerClient

1 class TimedDoor extends Door {
2 void doorTimeOut() { }
3 }
4
5 class DoorTimerAdapter implements TimerClient {
6
7 private TimedDoor timedDoor;
8
9 public DoorTimerAdapter(TimedDoor door) {
0
1 }
2
3 void TimeOut(int timeOutId) {
4 timedDoor.doorTimeOut();
5 }
6
7 }

SOLID Dependency inversion principle
Agenda
Hacia los objetos
2 SOLID
3 Testing
Dependencias

Propiedad
Deber´ıamos depender de Abstracciones y no de implenentaciones.

Cuando dise˜namos una API, usualmente lo hacemos pensando en lo
que la API necesita

que la API necesita
Cuando en realidad deber´ıamos pensar lo que el cliente necesita

que la API necesita
Cuando en realidad deber´ıamos pensar lo que el cliente necesita
Esto invierte la dependencia

Testing
Agenda
Hacia los objetos
2 SOLID
3 Testing
Dependencias

Testing Test First Development
Agenda
Hacia los objetos
2 SOLID
3 Testing
Dependencias

Tipos de Tests
Unit Test: Prueba clases y m´etodos, usualmente corren r´apido y
ayudan a aislar cuando un error ocurre

Tipos de Tests
Integration Test: Prueba el comportamiento de componentes, y sus
dependencias.

Tipos de Tests
Integration Test: Prueba el comportamiento de componentes, y sus
dependencias.
System Test: Prueba el sistema entero.

Que es TDD?
Test Driven Development no es una metodolog´ıa de test

Que es TDD?
Test Driven Development es una metodolog´ıa de dise˜no

Que es TDD?
Test Driven Development es una metodolog´ıa de dise˜no
No deja de lado el uso de QA, pero ayuda!

Test Driven es Test First
TDD signiﬁca diferentes cosas para diferentes personas.

Test Driven es Test First
TDD signiﬁca diferentes cosas para diferentes personas.
Para nosotros, signiﬁca primero Testear

¿Testear primero o al ﬁnal?
Si escribimos los Tests al principio ganamos algo de valor en cada
paso.

¿Testear primero o al ﬁnal?
Si escribimos los Tests al principio ganamos algo de valor en cada
paso.
Si escribimos los Tests al ﬁnal, solo tenemos buenas noticias o malas
noticias.

¿Como puede ser más rápido?
Cada clase que se utilice producción tiene una clase de Test

Cada método que se utilice en producción tiene un método de Test

Cada método que se utilice en producción tiene un método de Test
¿Como escribir más código puede ser más rápido?

¿Que dejamos de hacer?
se vuelven una forma de requerimientos, dejamos de pasar tiempo
escribiendo documentos de requerimientos

nos ayudan a encontrar bugs mas r´apido, pasamos menos tiempo en
el debugger

el debugger
nos ayudan a integrar c´odigo, pasamos menos tiempo integrando
c´odigo

el debugger
nos ayudan a integrar código, pasamos menos tiempo integrando
código
nos dan energ´ıa y confianza

Primero testear
Escribir test puede ser incomodo al principio

Primero testear
Con la practica se vuelve mucho m´as f´acil

Primero testear
Con la practica se vuelve mucho más fácil
Nos ayuda a diseñar lo que queremos construir

Lento m´as que r´apido
Aprender algo nuevo siempre es dif´ıcil al principio

Una vez que uno se vuelve bueno, se vuelve mucho mas r´apido

Una vez que uno se vuelve bueno, se vuelve mucho mas rápido
Equipos usando TDD reportan un incremento de un 20˜50 % de
velocidad y un 80 % de reducción de defectos el primer año

Empujar el desarrollo con Test
Escribir Tests antes de escribir la implementaci´on

Refactor, para mejorar la calidad

Mocks, stubs, y shunts

Mocks, stubs, y shunts
Inyecci´on de dependencias

Beneﬁcios de TDD
Enfocarse en buenos principios de dise˜no

Beneﬁcios de TDD
Separaci´on de responsabilidades: hacerlo funcionar y asegurar calidad

Beneﬁcios de TDD
Desarmar tareas complejas en tareas m´as simples

Beneficios de TDD
Desarmar tareas complejas en tareas más simples
Un conjunto completo de Tests de regresión

¿Por que funciona?
Nos mantiene enfocado en las tareas adecuadas en el momento
adecuado

¿Por que funciona?
adecuado
Separa las tareas en pedazos manejables

¿Por que funciona?
adecuado
Separa las tareas en pedazos manejables
Separa el desarrollo en la forma natural en la que pensamos

Herramientas para Test unitario
xUnit JUnit para java, NUnit para ˙Net

herramientas de cobertura de c´odigo

herramientas de cobertura de c´odigo
frameworks para Mocking

Los tres primeros pasos para testear
Escribir un Test que falle

Hacerlo andar

Hacerlo andar
Refactorizar por calidad

Rojo, Verde
Barra Roja: escribir un método que tenga una aserción en como se
deber´ıa llamar al método

Rojo, Verde
Barra Verde: Hacerlo andar!

Rojo, Verde
Refactorizar: Limpiarlo y hacerlo sop´ortale

Rojo, Verde
Refactorizar: Limpiarlo y hacerlo sop´ortale
Repetir

TDD no es directamente obtener la barra verde, es convertir la barra
roja en barra verde

roja en barra verde
Siempre hay que empezar con un test que falle

roja en barra verde
Si un test no falla estrepitosamente no es un test para nada

roja en barra verde
Si un test no falla estrepitosamente no es un test para nada
La veriﬁcaci´on de un test podr´ıa ser ver que un test fallo antes de
funcionar

Celebrar la barra Roja
Los Tests que son mas valiosos son los que fallan.

Tenemos que hacer un mont´on para obtener la barra roja

Tenemos que pensar que hace el m´etodo que queremos testear

Deﬁnir como lo vamos a llamar

Deﬁnir como lo vamos a llamar
Deﬁnir que va a devolver

Obteniendo la barra verde
Obtener la barra roja esta bien, quedarse ah´ı no

Obtener la barra verde puede ser f´acil, quedarse ah´ı no

Pasos separados:

Pasos separados:
Hacerlo andar

Pasos separados:
Hacerlo andar
Hacerlo mantenible

Refactorizar el Código
Limpiar la lógica, hacerla fácil de leer

Renombrar m´etodos, hacer que reﬂejen lo que hacen

Renombrar métodos, hacer que reflejen lo que hacen
Eliminar redundancia, encapsular variación

Refactorizar los Tests
Cuando uno est´a intentando entender que tiene que hacer,
probablemente escriba muchos tests

Este tipo de triangulaci´on puede ser ´util

Este tipo de triangulaci´on puede ser ´util
Los Tests extras, borrarlos!

Un ejemplo
Supongamos que quiero escribir una clase “adder”

Un ejemplo
Empezar´ıa escribiendo un test que falla

Un ejemplo
1 Adder adder = new Adder();
2 assertEquals(2, adder.add(1,1));

Un ejemplo
Y el c´odigo m´as simple para que compile

Un ejemplo
Y el c´odigo m´as simple para que compile
1 public class Adder {
2 public int add(int p1, int p2) {
3 return 0;
4 }
5 }

Una buena idea
Cual es la forma m´as r´apida de ir hacia la barra verde?

Una buena idea
Cual es la forma m´as r´apida de ir hacia la barra verde?
3 return 2;
4 }
5 }

Intentemos otro m´as

Opciones

Opciones
Podemos agregar l´ogica condicional

Opciones
3 if (p1 == 1 && p2 == 1) return 2;
4 if (p1 == 2 && p2 == 2) return 4;
5 return 0
6 }
7 }

Opciones
3 if (p1 == 1 && p2 == 1) return 2;
4 if (p1 == 2 && p2 == 2) return 4;
5 return 0
6 }
7 }
o simplemente

Opciones
3 if (p1 == 1 && p2 == 1) return 2;
4 if (p1 == 2 && p2 == 2) return 4;
5 return 0
6 }
7 }
o simplemente
3 return p1+p2
4 }
5 }

Caracter´ısticas de un buen test
Corren R´apido, deben tener un setup y un teardown cortos. Los test
deben correr aislados y no deber´ıa importar el orden en que corran.

Bien nombrados, si una abstracci´on no tiene un nombre adecuado
probablemente est´e mal

Bien nombrados, si una abstracci´on no tiene un nombre adecuado
probablemente est´e mal
Usar datos que representan como el sistema realmente va a ser
utilizado

Algunos TIPS
Hacer que el Test primero falle

Algunos TIPS
Hacer que los Tests corran r´apido testeando solo lo que se necesita
testear

Algunos TIPS
testear
No hay que asumir que los test corren en ning´un orden

Algunos TIPS
testear
Arrancar con el caso mas simple

Algunos TIPS
testear
Asegurarse que el Test mantiene valida una intenci´on

Algunos TIPS
testear
Mantener los Tests repetibles

Algunos TIPS
testear
No harcodear locaciones

Algunos TIPS
testear
No harcodear locaciones
Hacer los mensajes de error informativos

Que es dif´ıcil testear
M´etodos que retornan void

M´etodos static, o private

M´etodos que no son determiniticos

M´etodos que no son cohesivos

Jerarqu´ıa de clases profundas

Cuando se construyen objetos en los constructores

Cuando se construyen objetos en los constructores
Estado global

Preguntas para hacerse
Cuanto diﬁere TDD de lo que yo originalmente pensaba

Que beneﬁcio puedo obtener de TDD

Que beneﬁcio puedo obtener de TDD
Como decidir cual es el numero correcto de Unit Test por clase

Testing T´ecnicas de testing
Agenda
Hacia los objetos
2 SOLID
3 Testing
Dependencias

Fases de un test
Setup

Fases de un test
Setup
Ejercitarlo

Fases de un test
Setup
Ejercitarlo
Veriﬁcarlo

Fases de un test
Setup
Ejercitarlo
Veriﬁcarlo
Teardown

Dos tipos de test

Dos tipos de test
Boundary tests: deﬁnir condiciones de frontera

Dos tipos de test
Boundary tests: deﬁnir condiciones de frontera
Workﬂow tests: testear una secuencia de eventos

Boundary tests

Boundary tests
Los tests de fronteras est´an expresado por aserciones

Boundary tests
Usan alg´un framework de unit testing

Boundary tests
Usan alg´un framework de unit testing
Se aseguran que se retornen valores correctos para determinados
parametros

Workﬂow Testing

Workflow Testing
Los test de secuencia usan objetos de tipo Mock para inspeccionar y
verificar las llamadas hechas en una secuencia especifica

Workﬂow Testing
Usan un framework de mocking

Workﬂow Testing
Usan un framework de mocking
Aseguran que el ﬂujo funciona correctamente

Manejando las dependencias

No todo lo que testeamos est´a bajo nuestro control

Necesitamos poder manejar esas dependencias

Necesitamos poder manejar esas dependencias
Como hacemos para testear un webservice?

Mocks hechos a mano
Usualmente es una subclase de la clase que estamos mock-eando o
implementa la misma interface

Mocks hechos a mano
Contienen m´etodos para agregar y remover estado

Mocks hechos a mano
Contienen m´etodos para agregar y remover estado
Escritos a mano; no hay necesidad de ning´un framework

Mocks estaticos
Derivado de una clase, una interfase o un objeto

Mocks estaticos
Usualmente es generador por una herramienta de mocking

Mocks estaticos
Usualmente es generador por una herramienta de mocking
Es inspeccionable o se puede grabar

Mocks inspeccionables
Estos mocks pueden estar condicionados diciendo que deben esperar
Una vez que el mock esta creado, el código puede ser testeado
Después se verifica que las llamadas hayan sido correctas

Testing Dependencias
Agenda
Hacia los objetos
2 SOLID
3 Testing
Dependencias

En vez de hacer esto
1 public class MyClass {
2 public MyClass() throws IOException {
3 this.thread = new Thread();
4 this.fileWriter = new FileWriter(new File(‘‘myfile.txt’’));
5 }
6 }

Hacer esto
Delegar la creaci´on a una Factory
1 public class MyClassFactory {
2 public MyClass getWithDependencies() {
3 Thread thread = new Thread();
4 FileWriter fileWriter = new FileWriter(new File(‘‘myfile.txt’’
5 return new MyClass(thread, fileWriter)
6 }
7 }
8
9 public class MyClass {
0 public MyClass(Thread thread, FileWriter fileWriter) throws IOEx
1 this.thread = thread;
2 this.fileWriter = fileWriter;
3 }
4 }

Inyecci´on de dependencias
En esta t´ecnica pasamos la dependencia en el constructor
Esto nos habilita a pasar tipos cuando lo creamos conveniente

Otro ejemplo
1 public class Motorboat {
2 private Motor myMotor;
3
4 public Motorboat() {
5 myMotor = new V6_Cat_motor(); // oculta
6 }
7
8 }

Una opci´on
1
2 public Motorboat(Motor aMotor) {
3 myMotor = motor;
4 }
5
7 myMotor = new V6_Cat_motor();
8 }

Otra opci´on
2 myMotor = makeMotor();
3 }
4
5 protected static Motor makeMotor() {
6 return new V6_Cat_motor()
7 }

y una innerclass
1 public class MotorBoardTest {
2 private Motorboat testMotorboat;
3 static private Motor mockMotor = new MockMotor();
4
5 @Before
6 public void startupTest() {
7 testMotorboat = new TesteableMotorboat();
8 }
9
0 private class TesteableMotorboat extends Motorboat {
1 protected static Motor makeMotor() {
2 return mockMotor;
3 }
4 }
5 }

Gracias!

Técnicas de programación

Recommended

Recommended

More Related Content

Similar to Técnicas de programación

Similar to Técnicas de programación (20)

Técnicas de programación