Hace bien poco he leido un interesante artículo (en inglés) llamado "The empty try block mystery" que describe algunas secciones de código presentes en el código fuente del .NET Framework y que son similares a lo siguiente:
y que responde a la pregunta ¿porque diablos iba alguien a declarar un bloque try finally estando el try vacío? Pues vamos a explicarlo, en español ;)
En el artículo anterior vimos el uso más básico de la clausula SELECT de SQL, sin embargo apenas arañamos la superficie en cuanto a la cantidad de tipos de selecciones que podemos hacer.
En este segundo artículo vamos a explorar las posibilidades de los comandos de grupo que nos permiten realizar operaciones sobre las filas que devolvemos (como devolver una suma, o el número de filas) así como el uso de la orden GROUP BY que está íntimamente relacionado con lo anterior. Por otro lado exploraremos las intersecciones que se pueden realizar entre consultas (JOIN).
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.
Acabo de leer un artículo bastante interesante sobre el rendimiento del uso de excepciones en .NET (aunque en general el concepto es aplicable a prácticamente cualquier lenguaje que las soporte).
El manejado de una excepción, especialmente la parte correspondiente a su resolución implica un gran consumo de recursos y tiempo. Para los que no vayan muy bien con el inglés (o sean demasiado vagos para leer el artículo :P) lo que viene a demostrar es la diferencia entre estos dos segmentos de código
|
for (int i = 0; i < 1000000; i++)
{ string s = null; try{ string ss = s.Substring(0, 2); } catch (System.NullReferenceException) { } } |
for (int i = 0; i < 1000000; i++)
{ string s = null; if (s != null) { string ss = s.Substring(0, 2); } } |
observando que el código de la derecha tarda medio segundo frente a los nada más y nada menos que 50 segundos del código de la izquierada.
No obstante, aunque la comparación así hecha parezca nefasta, no debemos olvidar que la prueba lanza un total de un millon de excepciones consecutivas, algo que no es muy probable que pasé en la vida real, no obstante, si podemos comprobar que una llamada sea correcta antes de realizar, siempre será mucho mejor que capturar la excepción. En ese sentido es importante recalcar que lo importante es evitar la excepción en la medida de lo posible, no suprimir el bloque try catch, que en si mismo no genera ningún overhead, solo perdemos rendimiento cuando la excepción sucede, si no salta ninguna excepción la presencia o no de dicho bloque no afecta prácticamente al rendimiento.
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
El código y otra información adicional está disponible en la página del proyecto Monet Plugins Library y tenéis disponible la última versión del código en el control de versiones de subversion http://svn.thealphasite.org/Monet.
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).
En la entrega anterior vimos una pequeña introducción al comando SELECT de SQL. En él vimos el uso más básico de este comando, es decir, su uso para realizar consultas sencillas de selección y obtener datos de una o varias tablas.
En un 90% de las situaciones ese será el tipo de consultas que utilicemos, sin embargo en ocasiones, ese 10% restante, necesitamos algo más preciso, un comando de selección que nos permita obtener justamente los datos que necesitamos y que no se refieren directamente a una tabla sino que son, quizá, suma de dos o más tablas, intersecciones, obtener los resultados agrupados, ordenados, etc... La sentencia SELECT nos permite hacer todo este tipo de cosas.
Como ya vimos en la introducción anterior la sintaxis general de una consulta de selección SELECT es la siguiente: