Introducción

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

Introducción

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.

Introducción

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.

Sintaxis

Como ya vimos en la introducción anterior la sintaxis general de una consulta de selección SELECT es la siguiente:

Introducción

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.

Problema

El patrón Command se utiliza para resolver diversos tipos de problemas en desarrollo de software:

1. Usado como simplificación de llamadas. En ocasiones el numero de parametros de una función crece hasta hacerse inmanejable. El uso del patrón command permite agrupar los parametros en un solo objeto que se pasará a la función.
2. Usado como cola de comandos. Encapsular cada comando en un objeto permite su procesamiento de forma secuencial en forma de cola, de forma que un proceso trabajador pueda ir sacando los trabajos de dicha cola.
3. Operaciones con histórico. Usando objetos como comando y manteniendo esos comandos podemos mantener un histórico de los comandos utilizados y, en caso necesario, revertirlos.

Introducción

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

1. Preparar la pasta
2. Cocer la pasta
3. Preparar el sofrito
4. Freir el sofrito
5. Juntarlo todo

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.

Problema

Introducción

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

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.

Introducción

El patrón strategy (estrategia) esta orientado a resolver situaciones en las que nos encontramos con un problema base pero existen diversas estrategias para abordar el problema. En este sentido nuestro problema define un interface que será (o podrá ser) implementado de diversas formas.

Problema

El patrón Strategy aborda problemas que pueden (o se prevee que puedan) ser implementados o afrontados de distintas formas y cuyo interfaz esta bien definido y es común para dichas formas, pudiendo ser cualquiera de ellas valida o más desable en determinadas situaciones y permitiendo el cambio entre las distintas estrategias en tiempo de ejecución.

Estructura

Código de ejemplo

Introducción

La idea detrás del patron Abstract Factory (que en español se traduciría como fabrica abstracta) consiste en la noción de que nuestro programa (o el cliente de una clase que nosotros proporcionamos) trabaja con una serie de productos (como los de una fábrica) que tienen unas determinadas características (por ejemplo tenemos productos embotellados y productos en tetrabrick). Nuestro programa va a utilizar dichos productos realizando una serie de acciones sobre ellos (como meter las botellas en unos camiones y los tetrabricks en otros) sin importarle quien le está suministrando los productos.

Antes de empezar

Un sistema de plugins es un mecanismo complejo. Por un lado el traslado de dependencias hacia el tiempo de ejecución (como veremos más adelante) lo hace mucho más complicado de explicar, de comprender y de implementar. Hay muchas cuestiones a tener en cuenta, este artículo trata de abarcar las principales pero me temo que hay muchas cuestiones que quedarán fuera.

Por otro lado, aunque para entender el sistema no es necesario un conocimiento de .NET o C#, desde luego estos puntos ayudarán a comprenderlo mejor y con más profundidad.

Evidentemente el sistema es demasiado complejo para que explique aquí todas y cada una de las partes que componen el sistema. El código en si, que incluyo en el artículo, está bastante comentado y he procurado ilustrar en el artículo las partes principales del sistema pero no me cabe duda de que habrá zonas que queden sin comentar.

Introducción

Hace poco me he encontrado en el trabajo con un programa que estaba haciendo estaba teniendo pérdidas de memoria, no demasiada cada vez pero si lo suficiente como para convertirse en un problema a medio plazo.

Cuando te encuentras un problema de consumo de memoria lo más habitual es mirar el código de la zona en la que piensas que puede estar el problema intentando encontrar el lugar donde consumes memoria que luego no vas a liberar, o bien recurrir a algún programa de monitorización de memoria que te ayude a encontrar dichos problemas (yo no he tenido suerte con ellos).