Ultimamente, aquí y allá estoy oyendo hablar del llamado Test Driven Development o Desarrollo guiado por las pruebas como nueva metodología de desarrollo.
Dejadme que os explique un poco como funciona el asunto. La metodología se basa en que el desarrollo de los test guie el desarrollo de la aplicación, de esta forma lo primero que hacemos es planear que necesita hacer la aplicación y en función de ello desarrollamos test para cada una de las funciones, de esta forma disponemos de una prueba para cada función (no os entusiasmeis demasiado con esto ...)
El siguiente paso evidentemente es desarrollar la funcionalidad que consigue pasar ese test, y por tanto, funcionalidad hecha y medianamente probada... perfecto.
La descripción de la metodología tiene más pasos y más guías para el desarrollo y como realizar cada paso. La página de la wikipedia tiene más información para los interesados (que espero que después de leer este artículo sean pocos).
El patrón Adapter (o adaptador), también conocido a veces como wrapper realiza la función, como su nombre indica de adaptar (o envolver) una determinada clase cambiando el interfaz de dicha clase y convirtiendolo en algo que se acerque más a nuestras necesidades.
En muchas ocasiones tenemos una clase que hace lo que necesitamos (o se aproxima mucho) y cumple todos los requisitos para que alguna otra clase la use pero, al no implementar un determinado interface o derivar de una determinada clase esto no es posible.
En muchas ocasiones deseamos guardar el estado de un objeto de forma que podamos recuperar dicho estado en cualquier momento. Un ejemplo muy simple es que vayamos a modificar una serie de parametros del objeto y hacer alguna operación pero deseemos almacenar en que estado estaba ese objeto para poder volver a él en caso de que se produzca una excepción.
En la mayoría de los objetos existe una parte de su estado que queda recogida en variables privadas. Al contrario de lo que se suela pensar una campo es privado no para evitar que alguien pueda modificarlo (que tangencialmente también) sino para indicar al programador que usa la clase que dicho campo no le interesa y no debe tenerlo en cuenta, utilizarlo ni depender en ningún sentido. Si cambiamos dichas variables de privadas a publicas, conseguimos que quien quiere guardar el estado pueda hacerlo leyendo y almacenando los campos pero violamos el concepto anterior.
El atributo "Obsolete" nos permite marcar un elemento de código como obsoleto y asignar un comentario o mensaje de aviso en caso de que se utilice dicho elemento de código. Adicionalmente permite pasar un valor booleano que indique si el atributo se comportará como un error o como un warning.
El uso del atributo resulta útil conforme nuestro código va evolucionado. Quizá una función o una clase que diseñamos hace tiempo para una biblioteca ya no sea la forma más eficiente de hacer las cosas, de forma que queremos sustituir la función o la clase con otra nueva. En este caso el uso del atributo obsolete nos permite mantener la clase o función de forma que un desarrollador que estuviera utilizando la función no se encuentre con que ha desaparecido sin saber por qué sino con un warning (o un error en caso de que así lo hallamos definido) avisándole de que cambie y, preferiblemente, indicándole los pasos a realizar. Vamos a ver un ejemplo muy típico:
La librería reflection de .NET nos va a permitir acceder a la información de los atributos que hemos definido en el artículo anterior.
Reflection es el nombre dado por microsoft al conjunto de utilidades que permite leer la información y metainformación de las dll y ejecutables de .NET en tiempo de ejecución. Su utilidad fundamental está contenida en la biblioteca System.Reflection y contiene diversas funciones para cargar ensamblados, crear objetos, invocar métodos o leer información, todo ello en tiempo de ejecución.
Este artículo se centrará unicamente en el uso de .NET para leer la información de atributos, aunque se hará uso de otras funciones para acceder a las clases o los métodos involucrados. Para más información os recomiendo que leáis el artículo sobre .NET Reflection
Una de las posibilidades que incluye .NET es el uso de atributos para proporcionar metainformación añadida a las distintas partes del código que creamos.
Los atributos de .NET nos proporcionan una poderosa herramienta para añadir información a nuestras clases, métodos, propiedades etc.
Un atributo puede aplicarse puede aplicarse sobre cualquier elemento básico de .NET es decir, clases, eventos, propiedades, métodos, etc y añadirá información a dicho elemento que posteriormente podremos consultar en tiempo de diseño, compilación o ejecución.
El uso de atributos nos permite acercar la programación en .NET al concepto de AOP, que son las siglas inglesas de Aspect Oriented Programing o Programación arientada a aspectos.
Para comprender correctamente en que consiste el paradigma de programación orientada a aspectos debemos partir de la base de las limitaciones de la programación orientada a objetos. En el paradigma orientado a objetos, el concepto de herencia describe las relaciones jerárquicas entre los distintos objetos que a su vez modelan el mundo real (o conceptos de este).
El patrón Command (command pattern) es un patrón de diseño en el que los objetos representan acciones que serán consumidas por algún consumidor.
El patrón Command se utiliza para resolver diversos tipos de problemas en desarrollo de software:
En estos tiempos, con las modernas aplicaciones informáticas que existen hoy en día, los programadores en ocasiones olvidamos que tanto los propios ordenadores como los programas que ejecutan sobre ellos no son más que procesadores de datos, procesadores rápidos, pero procesadores a fin de cuentas.
Los programas en realidad recojen datos del usuario, de archivos en el ordenador, de la entrada de los periféricos y los transforman para producir otros datos. Una aplicación como el photoshop por ejemplo recoje los datos almacenados en forma de bytes en un fichero y permite al usuario mediante la introducción de toda una serie de datos modificarlos para crear otra imagen distinta. La tarjeta gráfica transforma una serie de datos en forma de stream de bytes en secuencias de 24 bits que a su vez el monitor transforma en pixels en la pantalla.
El patrón de diseño Template Method se utiliza en situaciones en las cuales existe un determinado esqueleto que conforma pasos comunes dentro de un algoritmo o procedimiento en una clase.
Una analogía podría ser la resolución del problema de cocina, por ejemplo, para hacer un plato de pasta podríamos distinguir entre
Ahora bien, el algoritmo es el mismo cada vez que queremos preparar pasta, sin embargo cada uno de dichos pasos puede realizarse de forma distinta dependiendo del Chef, la pasta puede cocerse con aceite o con mantequilla, por ejemplo y el sofrito puede llevar cebolla o no. Es posible que incluso queramos "combinar" los saberes de varios cocineros y dejar que cada uno de ellos se encargue de una tarea.

Los safeguards son el nombre que recibe un ingenioso mecanismo que nos permite, en cierto sentido, olvidarnos de los problemas asociados a liberar memoria en Delphi y que simulan de alguna forma el funcionamiento de un recolector de basura. En C++, para aquellos que han trabajado alguna vez con él, este mecanismo se conoce como Smart Pointers.
El truco para "olvidarnos" de liberar los objetos cuando terminamos con ellos consiste en el uso de interfaces. En delphi los interfaces incorporan un mecanismo de conteo referencial automático. Esto significa que cuando no se van a usar más (por ejemplo cuando salen de ámbito o cuando se "sobreescriben" y no quedan referencias al objeto que implementa dicho interface) se destruyen automáticamente.