Posted on

TDD by Example con Python 3

Después de leer Test Driven Development- By Example (Addison-Wesley Signature Series) me quedo un sensación mixta de intranquilidad.

Seguí los ejemplos del libro, la primera parte usando C#; aunque el libro usa Java y la segunda parte con Python 3.1, haciendo algunas adecuaciones al código del libro. De hecho, primero lo intente con IronPython para seguir con el tema de .Net, pero con Python 3.1 y IDLE me fue más fácil hacer trabajar el código.

TDD es una técnica avanzada que en su expresión ortodoxa no es seguida ni por el mismo Beck. Es fácil caer en callejones sin salida y el desarrollador debe tener un plan top-down  implícito basado en su experiencia y dominio técnico. Por otro lado su aceptación y referencias de éxito son evidencia de su validez.

La primera parte del libro me pareció incompleta, llena de manitas de puerco, visión nocturna, multiplicaciones por el número que pensaste, y conjuros de magia negra.

la segunda parte es de más alto nivel de abstracción pero muestra claramente los fundamentos del marco de xUnit. El uso de Python aquí parece apropiado ya que permite desarrollar la estructura básica de xUnit de manera clara y directa.

En resumen, Test Driven Development- By Example es un buen libro para desarrolladores expertos.

Referencias

Test Driven Development- By Example (Addison-Wesley Signature Series)

http://dinsdale.python.org/dev/peps/pep-0008/

http://docs.python.org/3.1/tutorial/index.html

http://www.python.org/

http://www.swaroopch.com/notes/Python

http://www.wrox.com/WileyCDA/

http://www.wrox.com/WileyCDA/Section/Browse-Titles-for-Code-Downloads.id-105127.html

http://www.wrox.com/WileyCDA/WroxTitle/Python-Create-Modify-Reuse.productCd-0470259329,descCd-DOWNLOAD.html

http://pybites.blogspot.com/

Posted on

Abstract classes vs. interfaces

Usar interfaces cuando se esperan cambios frecuentes en el código. Interfaces es un método más flexible que herencia para manejar opciones de comportamiento. Una clase abstracta funciona de manera similar pero además permite definir comportamientos comunes, forzando a las subclases a definir los comportamientos especializados. Una clase abstracta se parece a una interface en que ambos son una especie de contrato de como se debe comportar la clase en el mundo exterior. Resumiendo; interfaces permite a una clase tener varios padres, pero una interface no implementa ningún método, solo especifica que métodos se deben implementar.

Una clase abstracta no se puede instanciar pero puede implementar algunos métodos ( o todos). Interfaces hacen oficial la separación entre implementación y la firma de una clase, mientras que una clase abstracta permite definir comportamiento común, pero por lo mismo es más fácil romper el código en cascada al hacer un cambio. La siguiente tabla compara interfaces y clases abstractas en C#

Interface Abstract class
Una clase puede heredar múltiples interfaces. Una clase solo puede heredar de una clase abstracta.
sin implementación por defecto. Implementación por defecto.
Solo Static final constants. Constantes pueden ser estáticas y de instancia.
La interface define las características periféricas de una clase. Una clase abstracta define el comportamiento interno de una clase.
Si las implementaciones solo se parecen en la firma, entonces es mejor usar interfaces. Si las varias implementaciones usan comportamientos comunes, es mejor usar una clase abstracta.
Ejecución Lenta. Ejecución rápida.
Es necesario revisar todas las implementaciones para  agregar funcionalidad. Se puede agregar el nuevo método a la clase abstracta y todas las implementaciones lo incorporan.

http://www.javaworld.com/javaworld/javaqa/2001-04/03-qa-0420-abstract.html?page=1
http://www.codeproject.com/csharp/abstractsvsinterfaces.asp
C# Interface Based Development