Técnicas de programación

Tecnicas avanzadas de programacion. . . o como hacer software sin morir en el intento

Jose Luis Diaz

26 de junio de 2014

Jose Luis Diaz 26 de junio de 2014 1 / 80

Principios de diseno

Agenda

1 Principios de disenoOcultacion de la informacionHacia los objetos

2 SOLIDSingle responsibility principleOpen-closed principleLiskov substitution principleInterface segregation principleDependency inversion principle

3 TestingTest First DevelopmentTecnicas de testingDependencias

Principios de diseno Ocultacion de la informacion

Agenda

Diseno

¿Por que disenar?

Incorporar nuevos requerimientos evitando que el diseno se degrade.

Los cambios puedan incorporarse con el menor costo posible.

Hacer el caso comun facil, el caso complejo posible (Joshua Bloshsobre los lenguajes)

Diseno

¿Por que disenar?

Diseno

¿Por que disenar?

Diseno

¿Por que disenar?

Parnas

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

Identificar potenciales componentes. Detectar desde losrequerimientos los que mas vayan a cambiar.

Se contraen y expanden los requerimientos de estos componentes.

Aislar estos componentes y generar interfaces que toleren estoscambios anticipados.

Parnas

Principios de diseno Hacia los objetos

Agenda

Limitaciones

Limitaciones del diseno basado en ocultacion de informacion.

Incluir todos los metodos de la interfaz de un modulo correspondientecomo un parametro.

Generar varios modulos iguales.

Poder tener varias implementaciones diferentes de un mismo moduloy poder intercambiarlos.

Limitaciones

Agenda

SOLID Single responsibility principle

Agenda

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

Este principio fue originalmente descripto como “cohesion”, larelacion funcional de los elementos de una clase.

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

Este principio fue originalmente descripto como “cohesion”, larelacion funcional de los elementos de una clase.

¿Por que es importante este principio?

Si una clase tiene mas de una responsabilidad, entonces lasresponsabilidades estan acopladas.

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

Este tipo de acoplamiento conduce a disenos fragiles que se rompende manera inesperada cuando las clases cambian.

Aplicación de geometría

computacionalAplicación gráfica

Rectángulo

+ dibujar()+ area(): double

Aplicación de geometría

computacionalAplicación gráficaGUI

Rectángulo

+ dibujar()

RectánguloGeométrico

+ area(): double

SOLID Open-closed principle

Agenda

Open-closed principle

Primera ves enunciada por Ivar Jacobson y luego reexpresada porBertran Meyer en “Object Oriented Software Construction”:

“Las entidades de software (clases, modulos, funciones, etc). Debenestar abiertas para extension, pero cerradas para modificacion”

Esforzarse para hacer que cuando el codigo cambie, solo lugar en unlugar.

Open-closed principle

Primera ves enunciada por Ivar Jacobson y luego reexpresada porBertran Meyer en “Object Oriented Software Construction”:

“Las entidades de software (clases, modulos, funciones, etc). Debenestar abiertas para extension, pero cerradas para modificacion”

Esforzarse para hacer que cuando el codigo cambie, solo lugar en unlugar.

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) {

10 dibujarCuadrado(((Cuadrado) figura).lado);11 }12 else if (figura instanceof Circle) {13 dibujarCirculo(((Circle) figura).radio);14 }15 }16 }17

18 private void dibujarCirculo(double radio) {}19 private void dibujarCuadrado(double lado) {}20 }

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() {10 for (Dibujable figura: figuras) {11 figura.dibujar()12 }13 }14

SOLID Liskov substitution principle

Agenda

Liskov substitution principle

Propiedad

Propiedad de sustitucion: Si para cada objeto o1 de tipo S hay un objetoo2 de tipo T tal que: para todo programa P que se define en terminos deT, el comportamiento de P no varia cuando o1 es sustituido por o2entonces S es un subtipo de T.

Una clara violacion 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 compilando7 String y = ys.iterator().next();

SOLID Interface segregation principle

Agenda

Interface segregation principle

Propiedad

Ningun 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 }

11 interface TimerClient {12 public void timeOut();13 }

TimerClient

Door TimedDoor

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) {10

11 }12

13 void TimeOut(int timeOutId) {14 timedDoor.doorTimeOut();15 }16

SOLID Dependency inversion principle

Agenda

Dependency inversion principle

Propiedad

Deberıamos depender de Abstracciones y no de implenentaciones.

Cuando disenamos una API, usualmente lo hacemos pensando en loque la API necesita

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

Esto invierte la dependencia

Testing

Agenda

Testing Test First Development

Agenda

Tipos de Tests

Unit Test: Prueba clases y metodos, usualmente corren rapido yayudan a aislar cuando un error ocurre

Integration Test: Prueba el comportamiento de componentes, y susdependencias.

System Test: Prueba el sistema entero.

Tipos de Tests

Que es TDD?

Test Driven Development no es una metodologıa de test

Test Driven Development es una metodologıa de diseno

No deja de lado el uso de QA, pero ayuda!

Que es TDD?

Test Driven es Test First

TDD significa diferentes cosas para diferentes personas.

Para nosotros, significa primero Testear

Test Driven es Test First

TDD significa diferentes cosas para diferentes personas.

Para nosotros, significa primero Testear

¿Testear primero o al final?

Si escribimos los Tests al principio ganamos algo de valor en cadapaso.

Si escribimos los Tests al final, solo tenemos buenas noticias o malasnoticias.

¿Testear primero o al final?

Si escribimos los Tests al principio ganamos algo de valor en cadapaso.

Si escribimos los Tests al final, solo tenemos buenas noticias o malasnoticias.

¿Como puede ser mas rapido?

Cada clase que se utilice produccion tiene una clase de Test

Cada metodo que se utilice en produccion tiene un metodo de Test

¿Como escribir mas codigo puede ser mas rapido?

¿Que dejamos de hacer?

se vuelven una forma de requerimientos, dejamos de pasar tiempoescribiendo documentos de requerimientos

nos ayudan a encontrar bugs mas rapido, pasamos menos tiempo enel debugger

nos ayudan a integrar codigo, pasamos menos tiempo integrandocodigo

nos dan energıa y confianza

Primero testear

Escribir test puede ser incomodo al principio

Con la practica se vuelve mucho mas facil

Nos ayuda a disenar lo que queremos construir

Primero testear

Lento mas que rapido

Aprender algo nuevo siempre es difıcil al principio

Una vez que uno se vuelve bueno, se vuelve mucho mas rapido

Equipos usando TDD reportan un incremento de un 2050 % develocidad y un 80 % de reduccion de defectos el primer ano

Empujar el desarrollo con Test

Escribir Tests antes de escribir la implementacion

Refactor, para mejorar la calidad

Mocks, stubs, y shunts

Inyeccion de dependencias

Beneficios de TDD

Enfocarse en buenos principios de diseno

Separacion de responsabilidades: hacerlo funcionar y asegurar calidad

Desarmar tareas complejas en tareas mas simples

Un conjunto completo de Tests de regresion

Beneficios de TDD

¿Por que funciona?

Nos mantiene enfocado en las tareas adecuadas en el momentoadecuado

Separa las tareas en pedazos manejables

Separa el desarrollo en la forma natural en la que pensamos

¿Por que funciona?

Herramientas para Test unitario

xUnit JUnit para java, NUnit para Net

herramientas de cobertura de codigo

frameworks para Mocking

Los tres primeros pasos para testear

Escribir un Test que falle

Hacerlo andar

Refactorizar por calidad

Hacerlo andar

Rojo, Verde

Barra Roja: escribir un metodo que tenga una asercion en como sedeberıa llamar al metodo

Barra Verde: Hacerlo andar!

Refactorizar: Limpiarlo y hacerlo soportale

Repetir

Rojo, Verde

Repetir

Rojo, Verde

Repetir

Rojo, Verde

Repetir

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

Siempre hay que empezar con un test que falle

Si un test no falla estrepitosamente no es un test para nada

La verificacion de un test podrıa ser ver que un test fallo antes defuncionar

Celebrar la barra Roja

Los Tests que son mas valiosos son los que fallan.

Tenemos que hacer un monton para obtener la barra roja

Tenemos que pensar que hace el metodo que queremos testearDefinir como lo vamos a llamarDefinir que va a devolver

Tenemos que pensar que hace el metodo que queremos testear

Definir como lo vamos a llamarDefinir que va a devolver

Tenemos que pensar que hace el metodo que queremos testearDefinir como lo vamos a llamar

Definir que va a devolver

Obteniendo la barra verde

Obtener la barra roja esta bien, quedarse ahı no

Obtener la barra verde puede ser facil, quedarse ahı no

Pasos separados:

Hacerlo andarHacerlo mantenible

Pasos separados:

Hacerlo andar

Hacerlo mantenible

Pasos separados:

Refactorizar el Codigo

Limpiar la logica, hacerla facil de leer

Renombrar metodos, hacer que reflejen lo que hacen

Eliminar redundancia, encapsular variacion

Refactorizar los Tests

Cuando uno esta intentando entender que tiene que hacer,probablemente escriba muchos tests

Este tipo de triangulacion puede ser util

Los Tests extras, borrarlos!

Un ejemplo

Supongamos que quiero escribir una clase “adder”

Empezarıa escribiendo un test que falla

Y el codigo mas simple para que compile

Un ejemplo

Empezarıa escribiendo un test que falla

Un ejemplo

Empezarıa escribiendo un test que falla1 Adder adder = new Adder();2 assertEquals(2, adder.add(1,1));

Un ejemplo

Y el codigo mas simple para que compile1 public class Adder {2 public int add(int p1, int p2) {3 return 0;4 }5 }

Una buena idea

Cual es la forma mas rapida de ir hacia la barra verde?

Una buena idea

Cual es la forma mas rapida de ir hacia la barra verde?1 public class Adder {2 public int add(int p1, int p2) {3 return 2;4 }5 }

Intentemos otro mas

1 assertEquals(4, adder.add(1,1));

Opciones

Podemos agregar logica condicional

o simplemente

Opciones

Podemos agregar logica condicional

o simplemente

Opciones

Podemos agregar logica condicional1 public class Adder {2 public int add(int p1, int p2) {3 if (p1 == 1 && p2 == 1) return 2;4 if (p1 == 2 && p2 == 2) return 4;5 return 06 }7 }

o simplemente

Opciones

o simplemente

Opciones

o simplemente1 public class Adder {2 public int add(int p1, int p2) {3 return p1+p24 }5 }

Caracterısticas de un buen test

Corren Rapido, deben tener un setup y un teardown cortos. Los testdeben correr aislados y no deberıa importar el orden en que corran.

Bien nombrados, si una abstraccion no tiene un nombre adecuadoprobablemente este mal

Usar datos que representan como el sistema realmente va a serutilizado

Algunos TIPS

Hacer que el Test primero falle

Hacer que los Tests corran rapido testeando solo lo que se necesitatestear

No hay que asumir que los test corren en ningun orden

Arrancar con el caso mas simple

Asegurarse que el Test mantiene valida una intencion

Mantener los Tests repetibles

No harcodear locaciones

Hacer los mensajes de error informativos

Algunos TIPS

Que es difıcil testear

Metodos que retornan void

Metodos static, o private

Metodos que no son determiniticos

Metodos que no son cohesivos

Jerarquıa de clases profundas

Cuando se construyen objetos en los constructores

Estado global

Preguntas para hacerse

Cuanto difiere TDD de lo que yo originalmente pensaba

Que beneficio puedo obtener de TDD

Como decidir cual es el numero correcto de Unit Test por clase

Testing Tecnicas de testing

Agenda

Fases de un test

Ejercitarlo

Verificarlo

Teardown

Fases de un test

Ejercitarlo

Verificarlo

Teardown

Fases de un test

Ejercitarlo

Verificarlo

Teardown

Fases de un test

Ejercitarlo

Verificarlo

Teardown

Dos tipos de test

Boundary tests: definir condiciones de frontera

Workflow tests: testear una secuencia de eventos

Dos tipos de test

Boundary tests

Los tests de fronteras estan expresado por aserciones

Usan algun framework de unit testing

Se aseguran que se retornen valores correctos para determinadosparametros

Boundary tests

Workflow Testing

Los test de secuencia usan objetos de tipo Mock para inspeccionar yverificar las llamadas hechas en una secuencia especifica

Usan un framework de mocking

Aseguran que el flujo funciona correctamente

Workflow Testing

Manejando las dependencias

No todo lo que testeamos esta bajo nuestro control

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 oimplementa la misma interface

Contienen metodos para agregar y remover estado

Escritos a mano; no hay necesidad de ningun framework

Mocks hechos a mano

Mocks estaticos

Derivado de una clase, una interfase o un objeto

Usualmente es generador por una herramienta de mocking

Es inspeccionable o se puede grabar

Mocks estaticos

Mocks inspeccionables

Estos mocks pueden estar condicionados diciendo que deben esperar

Una vez que el mock esta creado, el codigo puede ser testeado

Despues se verifica que las llamadas hayan sido correctas

Testing Dependencias

Agenda

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 creacion a una Factory1 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 {10 public MyClass(Thread thread, FileWriter fileWriter) throws IOException {11 this.thread = thread;12 this.fileWriter = fileWriter;13 }14 }

En esta tecnica 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(); // oculta6 }7

Una opcion

2 public Motorboat(Motor aMotor) {3 myMotor = motor;4 }5

6 public Motorboat() {7 myMotor = new V6_Cat_motor();8 }

Otra opcion

1 public Motorboat() {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 @Before6 public void startupTest() {7 testMotorboat = new TesteableMotorboat();8 }9

10 private class TesteableMotorboat extends Motorboat {11 protected static Motor makeMotor() {12 return mockMotor;13 }14 }15 }

Gracias!

Técnicas de programación

Software

Transcript of Técnicas de programación