IEqualityComparer

Llegado a este punto, vamos a hacer un pequeño parón dentro de los operadores de consulta, para centrarnos en una interface muy útil dentro de la comparación de nuestros objetos, y que bajo mi opinión, mucha gente no le da la importancia que realmente tiene, hasta llegar al punto de que muchos autores ni siquiera le dediquen una línea dentro de libros dedicados por entero a LinQ.

En pocas palabras, la interface IEqualityComparer<T>, nos permite especificar nuestra propia clave de comparación, sin que para ello tengamos que redefinir ninguno de los métodos iniciales de la clase Object. Esto nos ofrece una versatilidad gigante, ya que podemos crear todos los que queramos según nuestras necesidades y nuestro modo de operar. Veremos que esto será clave en el uso de operadores como Group By, Distinct, Union, Intersect, etc.

Proyecciones en LinQ, La cláusula Select y SelectMany

Dentro del mundo de LinQ, las proyecciones, determinan el tipo de datos que será devuelto o proyectado cuando sea aplicado a uno de nuestras secuencias IEnumerable<T>.

 En este apartado estudiaremos los operadores de consulta Select y SelectMany. Hay otros autores y expertos en la materia que les gusta añadir en el apartado de proyecciones las cláusulas Join, GroupBy y GroupJoin, pero en este caso yo he preferido crear un apartado específico para cada una de ellas y así intentar no excederme demasiado en cada una de las entradas para hacerlas más comprensibles y dar más énfasis a cada una de ellas, aplicando casos prácticos de uso.

Claúsula Where

La cláusula where, representa el elemento de filtrado dentro del mundo de LinQ, al igual que en el lenguaje SQL. Esta es una de las más usadas y de las más útiles de todas las que componen su librería de métodos extensores (System.Linq).

La parte más importante dentro de la cláusula Where, es el llamado ‘Predicate’, este es un Parámetro de tipo Func<TSource, bool> que viene a indicar la condición del filtrado. Os facilito la entrada del blog donde se explican en detalle los delegados anónimos Func y donde podéis ampliar información sobre estos tipos.

Operadores de Consulta

Dentro del universo de LinQ, tenemos dos formas diferentes de realizar las llamadas y hacer uso de nuestros métodos de extensores de IEnumerable<T>, la primera es haciendo uso de las Expresiones Lambda, que vendría a representar un uso cotidiano de cualquier método extensor, y la segunda es utilizando el llamado azúcar sintáctico (formato de consulta) y que nos permite realizar una consulta de manera muy similar a como realizaríamos una llamada en el lenguaje SQL.

Es importante señalar que hay algunas opciones que no están disponibles dentro del formato de consulta, aunque son las mínimas, y que iremos viendo según vayamos estudiando los operadores (métodos extensores).

Ejecución Diferida (Lazy Loading)

La ejecución perezosa o diferida (Lazy Loading) es el comportamiento por defecto que usa LinQ para ejecutar, valga la redundancia, sus métodos extensores. A grandes rasgos viene a significar que los métodos no se ejecutan en el momento de realizar su llamada, sino que se ejecutan en el momento en que consumimos (utilizamos) alguno de los datos devueltos por esta llamada. Con todo esto el motor de LinQ se asegura el no realizar cálculos, cargas de datos, etc., que el usuario no necesite en ese momento.

IEnumerable, Entendiendo las secuencias ...

La Iterface IEnumerable<T>, es una de las partes más importantes de todo el mundo de LinQ, ya que todos sus métodos extensores están realizados sobre este tipo y prácticamente todos ellos devuelven objetos de este mismo tipo.

 Podemos entenderla como la mínima expresión de una colección, y prácticamente la mayoría de las colecciones del Framework la implementan (List<T>, Observable<T>, Arrays, etc). En esta parte tenemos que indicar que hay una minoría de ellas que no lo hacen y que principalmente están formadas por colecciones especiales de controles gráficos, tales como el UIElementCollection que es la colección en la que se guardan los objetos contenidos dentro de un Grid de WPF. Cuando estemos acostumbrados a trabajar con LinQ y nos encontremos con una de estas colecciones, lo primero que pensaremos es que o nos falta algún using, o el intellisense o el propio Visual Studio nos están jugando una mala pasada. Un poco más adelante dentro del curso aprenderemos a convertirlas fácilmente en colecciones compatibles con la tecnología.

Métodos de Extensión - Extensions Methods

Los métodos de extensión, nos ofrecen la posibilidad de poder extender las clases de terceros, de poder añadir métodos a clases de las que no disponemos del código fuente y nos es de utilidad añadirles nuevas funcionalidades.

Esta característica se añadió en la versión 3.0 del .Net Framework, y es masivamente utilizada dentro de las librerías de LinQ, especialmente para el tipo IEnumerable<T>, que veremos con posterioridad en la siguiente entrada.

Expresiones Lambda

Vamos con la evolución de los métodos anónimos, para muchos las muy polémicas y comprometidas Expresiones Lambda.

Aparecieron en la versión 3.0 del Framework y vinieron a ser el apoyo ideal para nuestro bien amado LinQ. Las Expresiones Lambda tienen la capacidad de manejar eventos ‘inline’ asignando bloques de código a delegados o eventos, al igual que lo hacían nuestros métodos anónimos, pero de una forma más reducida y concisa, ‘echando mano’ de la inferencia de tipos.

Intentaremos desmitificarlas haciendo una comparativa con los métodos anónimos y desglosando cada una de sus partes y sus formas de uso.

Métodos, Delegados Anónimos

Lo primero para ver este apartado es explicar que podemos encontrárnoslo como Métodos Anónimos o Delegados Anónimos, aunque también podemos referirnos a ellos como Funciones Anónimas, o Funciones o Métodos ‘Inline’. Aparecieron en la versión 2.0 del Framework y vinieron a cubrir la incapacidad de poder definir un método dentro de cualquier porción de código, sin tener que echar mano de la forma clásica [public/private void/int/string/ … nombreMétodo (parámetros)].

Esto como veremos en la siguiente entrega fue superado por creces con la introducción de la Expressiones Lambda en la versión del Framework 3.0 y con el concepto de Inferencia de Tipos, pero como veremos en esta hay una excepción que poseen los delegados anónimos que no pueden realizar las Expressiones Lambda.

Eventos - events

Los eventos son un tipo definido dentro del CLR que nos permite notificar a otros objetos algo que está sucediendo en el interior de nuestra clase. Para que estos objetos puedan ser informados, antes tienen que suscribirse al evento.

Desde la aparición de Visual Basic 6, normalmente achacamos los eventos a controles tales como Buttons, Combobox, DataGrids, etc., pero su aplicación y su enfoque va mucho más allá, y su uso en clases que no forman parte de la GUI, es tan normal, tan común y tan útil como en éstas.

El concepto de evento está completamente ligado al de delegado, ya que se nutre de estos para guardar las acciones que se suscriben al mismo, y así añadir su restricción de firma para estas acciones, de manera que solo se puedan suscribir a estos eventos los métodos que cumplan con la firma de su delegado.

Delegados - Delegates - parte 3

La covarianza y la contravarianza son uno de esos conceptos dentro de la programación que a priori, no solemos verles una funcionalidad o un uso demasiado práctico, pero que cuando manejas, te das cuenta que vienen a romper una serie de limitaciones que sin su existencia nos haría tener que decir eso de ‘no se puede hacer’ en más ocasiones al día. 

Esto no es menos importante para LinQ  ya que tienen una aparición estelar con los delegados genéricos Func.

Para finalizar también veremos la posibilidad de realizar ejecuciones asíncronas con nuestros delegados.

Delegados - Delegates - parte 2

Continuamos con la segunda parte de nuestros queridos delegados, esa clase tan útil, y utilizada por el framwork y tantas veces se nos hace tan complicada de entender.

En esta segunda parte nos centraremos principalmente en estudiar la clase base y los métodos y propiedades más importantes de ésta, que hacen que el delegado realice una series de funciones muy marcadas y en ocasiones totalmente transparentes para nuestro trabajo diario con ellos, ya que están ocultas dentro de la redefinición de operadores.

La segunda parte del post irá dirigida al uso de Generics con delegados. En ella profundizaremos en la importancia y la potencia que tienen para la ejecución de referencias a funciones y a métodos genéricos. También daremos un repaso a los delegados genéricos más importantes del Framework y de LinQ en general que no son otros que Func<T> y Action<T>.

Delegados - Delegates - parte 1

Los siguientes posts sobre Delegados que arrancamos con esta primera parte, pretenden ser algo más que una simple pasada sobre lo que nos ofrece esta clase del CLR y su uso en LinQ. Estos posts intentan profundizar dentro de su usabilidad en el Framework ya que considero que es una de las partes más difícil de comprender y de dominar, y su comprensión total, nos hace no tener ningún tipo de barrera en LinQ dentro de su parte más avanzada.

La definición más lógica que suele realizarse cuando hablamos de un delegado, es que es lo más parecido a un puntero a una función en C++. Esto no es del todo cierto, ya que un delegado es una clase y no un tipo. 

Propiedades Automáticas e Inicializadores de Objetos

Este post que cubre las propiedades automáticas y los inicializadores de objetos, es un post completamente de transición, en el que nos viene a mostrar una forma de realizar acciones que cotidianas, que a partir de la versión 3.0 del Framework, como casi todo lo que se añadió para LinQ, se pueden realizar de una forma más sencilla y escribiendo mucho menos código.

Son ampliamente conocidas, pero me ha parecido interesante dedicarle en post dentro del mundo LinQ, por si había por ahí algún despistadillo que no las conocía.

Tipos Anónimos

Los tipos anónimos son una característica introducida dentro del Framework 3.0.

Los tipos anónimos nos ofrecen la posibilidad de crear objetos al vuelo con propiedades de solo lectura, evitando tener que definir de manera explícita una clase para almacenar este tipo de datos equivalentes. 

Esta característica daba unas posibilidades de dinamismo a los desarrolladores de .Net solo reservada a lenguajes como JavaScript, Python, etc.

Asignación implícita de tipos, var

La palabra reservada var, viene a significar una asignación implícita de tipos. Esto se traduce en que el compilador será el que averigüe cual es el tipo que hay que asignar a esa variable, ósea utilizará la Inferencia de Tipos.

Cuando salieron las primeras noticas sobre esta mejora, trajo mucha controversia, al igual que los métodos extensores, dentro de la comunidad ya que muchos pensaban que esto rompía las buenas prácticas de programación y la fortaleza de tipos, cosa que no era cierta como veremos más adelante.

Es fácil confundir este tipo de variable con antiguo y costoso Variant de Visual Basic 6.0, o llegar a pensar que simplemente es un objeto de tipo object camuflado, pero nada de eso, es mucho más.

Inferncia de tipos

La inferencia de tipos, es una característica de los lenguajes funcionales  y consiste en la capacidad que tiene el compilador de predecir el tipo de una operación, método, asignación, etc., según los datos facilitados por el desarrollador dentro de la misma sentencia. Este proceso siempre se presenta en tiempo de compilación.

Esta novedad se dio por primera vez dentro del Framework 3.0, una entrega de framework muy poco utilizada y sin correspondiente versión de Visual Studio, por lo que muchos lo señalan como novedad del framework 3.5.

Normalmente la inferencia de tipos se suele achacar a los tipos anónimos (var), pero nosotros intentaremos darle un enfoque más general y trataremos para comenzar su uso con generics, para después verlo con tipos anónimos, y eventos y delegados, avanzadas en Expresiones Lambda, y árboles de expresiones que se escapan de nuestro tema principal.

La palabra reservada default(T)

Dentro del universo de Generics, existe un concepto que no suele ser demasiado conocido y que aunque puede ser sustituido por otro tipo de técnicas, ahorra mucho código y lo hace mucho más seguro y entendible para terceros.

Hablamos de la palabra reservada default(T), de la que hablaremos en este post para intentar darte un enfoque no solo teórico sino también práctico, en pos de intentar que sea mucho más familiar para ti, de ahora en adelante en tus desarrollos de Generics.

Restricciones en Generics

Hasta ahora, en la construcción de nuestros Generics, hemos dejado plena libertad para el consumidor, tanto si somos nosotros mismos, o si es algún usuario de alguna de nuestras librerías, de poder asignar el tipo que mejor le viniera dentro de nuestros parámetros de tipo. Esto en ocasiones, puede ser contraproducente para su uso, y lo que es peor puede limitarnos en demasía a la hora de realizar un desarrollo. Las restricciones dentro de Generics nos pueden ayudar a solventar todos estos problemas.

Problemas de uso de colecciones no genéricas

En las versiones anteriores a framework 2.0, era absolutamente normal trabajar con colecciones de tipo object como base, entre ellas ejemplos como ArrayList, Queue, List, etc., Esto traía dos problemas principales a los desarrolladores:

• Problemas de Conversion de Tipos.
• Problemas de rendimiento.

Vamos a ver de manera un poco más amplia cada uno de ellos.