Hola que tal, si bien este tema podría estar más que conocido, con esto pretendo crear los cimientos para programar en LINQ y no hay nada mejor que tener los conceptos y las nuevas características claras sobre todo para aquellos que empiezan a meterse a desarrollar con el framework 3.5, este es un buen comienzo, bueno dejemonos de tanto rollo y empecemos a ver las nuevas características.
C# 3.0, mueve a C# en dirección de un lenguaje funcional, dandole soporte a un estilo de codificación más declarativa. LINQ hace un amplio uso de todas las nuevas características, las cuales también nos permiten utilizar un mayor nivel de abstracción en el código en otros ámbitos distintos del LINQ.
Implementación automáticamente de propiedades.
La mayoría de las propiedades de un tipo son simples envoltorios de un miembro privado de datos del mismo tipo. La generación de código y entorno de desarrollo integrado (IDE por sus siglas en ingles) son las herramientas disponibles para acelerar la escritura de código como la siguiente:
private string _name;
public string Name {
get { return _name; }
set { _name = value; }
}
Con C# 3.0 puedemos obtener el mismo resultado (una propiedad envolviendo un miembro de datos privados) con una sola línea de código:
public string Name { get; set; }
La sintaxis apenas mostrada pide el compilador generar el codigo de los datos miembro y el codigo de acceso. La única diferencia con la declaración explícita es el nombre del dato miembro privado, que no es nombre, pero es autogenerado y no se puede acceder desde el código de clase, aunque sea privado para la propia clase.
Si en una futura versión de un programa en el cual necesitemos modificar el código de acceso, podemos volver a la sintaxis explícita. En ese caso, debemos declarar los datos miembro. Esta declaración no modificara el código existente porque el nombre del dato miembro privado no es accesible desde cualquier parte del código. Por esta razón, la nueva sintaxis no se puede utilizar para propiedades de sólo lectura o sólo escritura porque nuestro código tendría las mismas limitaciones. Sin embargo, siempre se puede diferenciar la accesibilidad get y set, como en el siguiente código:
public string Name { get; private set; }
Inferencia Local de Tipos.
La& inferencia de tipos es una magnifica característica de cualquier Lenguaje. Conserva la seguridad del tipo, mientras nos permite escribir un codigo más "relajado". En otras palabras, podemos definir variables y utilizarlas sin preocuparnos demasiado acerca de los tipos, dejando que el compilador determine el tipo correcto de una variable por inferencia a partir de la expresión de asignación a la variable misma.
El precio por usar la inferencia de tipos podría ser codigo menos explícito en contra de los tipos que desea utilizar. Sin embargo, en nuestra opinión, esta característica simplifica el mantenimiento del código de las variables locales donde la declaración explicita del tipo no es especialmente significativa.
C# 3.0 ofrece inferencia de tipos que nos permite definir una variable mediante el uso de la palabra reservada "var" en lugar de un tipo específico. Esto podría parecer equivalente a la definición de una variable de tipo objeto, pero no lo es. El siguiente código muestra un objeto que requiere boxing de un tipo de valor (véase la declaración b), y, en todo caso, requiere un cast cuando se quiere trabajar con el tipo específico (véase la& asignación d):
var a = 2; // a es declarada como int
object b = 2; // Boxing un int dentro de un object
int c = a; // No cast, no unboxing
int d = (int) b; // Cast es requerido, un unboxing es realizado
Cuando se utiliza var, el compilador infiere el tipo de la expresión utilizada para inicializar las variables. El código IL generado por el compilador contiene tipo inferido. Para otro ejemplo, considere lo siguinte:
int a = 5;
var b = a;
Es perfectamente equivalente al siguiente ejemplo:
int a = 5;
int b = a;
¿Por qué es esto importante? La palabra reservada "var" llamada por Component Object Model (COM) como tipo VARIANT, que se utilizó frecuentemente en Microsoft Visual Basic 6,0.En realidad, sin embargo, es absolutamente diferente porque se trata de una declaración de tipo-seguro. De hecho, como escribimos el código en Visual Studio, el tipo se infiere yel IntelliSense refleja el tipo real de la variable y nos proporciona la lista de los miembros de ese tipo. Como he explicado, cuando el código es compilado, el código IL generadoutiliza el tipo inferido, por lo que esta característica no romper la seguridad del tipo del lenguaje. Para algunos, podría parecer que la palabra reservada "var" es una herramientapara los programador perezoso. No obstante, var es la única manera de definir una variable de tipo anónimo, como describiré más adelante.
La palabra "var" se puede utilizar sólo dentro de un ámbito local. En otras palabras, una variable local se puede definir de esta manera, pero no un miembro o un parámetro. El siguiente código muestra algunos ejemplos de usos válidos de var: la x, y, r son double, d y w son decimales; s y p son strings, y q es un int. Tengamos en cuenta que la constante 2.3 define el tipo a inferirse de tres variables, y la palabra "default" es un string nulo que le permite al compilador inferir el tipo correcto de p.
public void ValidUse( decimal d )
var x = 2.3; // double
var y = x; // double
var r = x / y; // double
var s = "sample"; // string
var l = s.Length; // int
var w = d; // decimal
var p = default(string); // string}
El siguiente ejemplo muestra algunos casos en los que la palabra reservada var no está permitido:
class VarDemo {
// invalid token 'var' in class, struct or interface member declaration
var k =0;
// type expected in parameter list
public void InvalidUseParameter( var x ){}
// type expected in result type declaration
public var InvalidUseResult() { return 2; }
public void InvalidUseLocal() {
var x; // Syntax error, '=' expected
var y = null; // Cannot infer local variable type from 'null'
}
// . . .}
El tipo k se puede inferir por la inicializacion de la constante, pero "var" no se permite en los miembros tipo. El tipo del resultado de InvalidUseResult podría inferirse de la declaración interna en el "return", pero incluso esta sintaxis no está permitido.
Esta simple característica del lenguaje nos permite escribir código que prácticamente elimina casi todas las declaraciones de tipo variable. Si bien esto simplifica el código escrito, que puede hacer la lectura de código más difícil. Por ejemplo, si vamos a llamar a un método sobrecargado con versiones del método que difieren en los tipos de parámetros, podría ser poco claro de leer el código de la versión del método que se llama.
Similares problemas se generan a partir de la mala utilización del método de sobrecarga, hay que utilizar diferentes nombres método cuando el comportamiento (y el sentido) de los métodos es diferente.
Mejores Practicas en el uso de la inferencia local de tipos.
No se han encontrado mejores prácticas consistentes para el uso de la inferencia local de tipos C#. Estamos de acuerdo en que el uso de "var" de todo el mundo para declaración de variables locales, aunque sintácticamente correctos, no es buena práctica. En general, debemos usar la palabra "var" cuando es inevitable (por ejemplo, para almacenar los instancias de tipos anónimos, que se describirá más adelante). Por el contrario, debería usar un tipo explícito cuando no exista algun valor inicial, cuando un tipo no puede deducirse (por ejemplo, si el valor inicial es una expresión lambda), o cuando el tipo inferirse no es el que nosotros deseamos (por ejemplo, es demasiado específica).
En cualquier caso, debemos elegir entre "var" y de manera explícita el tipo y el uso de un código que mejore la legibilidad y mantenimiento. En la siguiente lista aparecen nuestra opinión sobre lo que da a lugar la prácticas más legible el código. Sin embargo, entendemos que un programador acostumbrado a lenguajes no requieren variables con tipo preferiran utilizar var en todas partes, pero esto no es recomendable. Tenga en cuenta que la siguiente lista de puntos a tipos anónimos y las expresiones de consultas, que serán cubiertos más adelante.
var c3 = new { Name = "Tom", Age = 31 };
var query = from c in customers where c.Discount > 3 select c;
var ordersByCustomer = new Dictionary<string, List<Orders>>();
var customer = new Customer();var numbers = new int[] { 1, 3, 5, 9 };
var x = 5; // Bad Practice
var amount = customer.Amount; // Bad Practice
var x = y // Bad Practice
var count = list.Count(); // Bad Practice
Pues bueno esto es un tema muy extenso y apenas es el principio, en el proximo tema tocare temas como expresiones lambda, extension de metodos, expresiones de inicializacion de objetos