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/

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

Los operadores de copia e igualdad.

Una de las trampas de la orientación a objetos en lenguajes como C# son los operadores de copia e igualdad.



En C# al usar el operador = o ==, la igualdad entre objetos referenciados solo se da si en realidad es el mismo objeto y de manera similar al hacer una copia nos podemos llevar una sorpresa si no tenemos cuidado de estar copiando la referencia o el contenido. Por eso la interfaz ICloneable es controversial porque su significado es ambiguo

Referencias:

Implementar ICloneable mediante serialización



ICloneable Interface

Should we Obsolete ICloneable (The SLAR on System.ICloneable)

IClonable deep vs shallow, best practise

Creating and Using Attributes in your .NET application

IEquatable Generic Interface

Comparación de Java y C#

Hace algunos años , en un lugar de cuyo nombre no quiero acordarme, se discutía el plan quinquenal del programa académicos en tecnologí­a de información. Los administradores del grupo, siguiendo linea del jefe divisional, decidieron normalizar el uso de Java para toda la curricula departamental. Algunos de los profesores expresamos tibias dudas sobre al asunto, pero no hubo realmente opiniones en contra.



A mi el incidente me recordó la tendencia histórica de los ejércitos del mundo a preparase para la guerra anterior sin comprender que el entorno tecnológico y social hacen inoperantes e irrelevantes enfoques que en el pasado hubieran sido determinativos e innovadores. La linea Magniot de los francés como ejemplo concreto.

Aunque Microsoft es más fiero como monopolio que como motor tecnológico, tiene el suficiente peso económico y social para absorber el mejor talento del mundo y el Sr. Puertas ha mostrado saber a donde va el puck.

Java sigue teniendo su lugar como herramienta de desarrollo inter-plataforma pero hay evidencias de que su mejor momento tal vez ya paso. Microsoft tiró el guante blanco al implementar la aplicación de referencia J2EE, PetShop, en .Net y obtuvo mejores números, tanto en lineas de código como en rendimiento. Cada vez que Java levantaba el guante, la evidencia era más contundente: .Net permite desarrollos en menos tiempo y con mejor rendimiento que J2EE.

En el mismo foro de desarrolladores de Java de Sun el consenso en el tema de manejo de genéricos fue que la implementación de C# es superior a la de Java.

Aunque hay diferencias de implementación, Java y C#, tienen puntos en común. Despues de todo, C# es la respuesta de Microsoft a Java. El articulo C# and Java: Comparing Programming Languages presenta una comparación detallada.

Un punto en común entre Java y C# es que no manejan herencia multiple y promueven el uso de interfaces para propositos equivalentes.

El sitio Desarrollo Profesional de Aplicaciones tiene bastante material didactico sobre .Net en español.