lunes, 4 de abril de 2016

Buenas prácticas de programación:

Principios de diseño SOLID - Liskov Substitution (4/6)

Es turno de hablar del tercer elemento dentro de los principios de diseño SOLID: Lisvov Substitution Principle (LSP).

Este es uno de los principios de diseño que causa más problemas para poder entender el concepto inicialmente, ya que establece: "Las entidades en un programa deberían ser reemplazables con objetos de sus subclases sin alterar el funcionamiento del programa". Esto en pocas palabras es: Si tienes una interfaz IAnimal que implementa un método Respirar() y decides implementar la interfaz para una clase llamada Amoeba y dentro de la implementación devuelves una excepción DeHechoNoRespiroException entonces no estás cumpliendo el principio de diseño señalado.


Un ejemplo de este principio aplicado en la vida real son los tipos de datos que devuelven los actions en MVC:
La interfaz que define el comportamiento de estos objetos es IHttpActionResult y la clase que implementa ésta interfaz es ActionResult. Pero en la vida real hay distintos tipos de clases que hereda de ActionResult y que definen lo que nuestro Action realmente va a devolver: JsonResult, FileResult, ViewResult y podemos intercambiar de forma indiferente el tipo de dato sin que nuestra aplicación truene:



En el ejemplo vemos que se cambia el tipo de dato devuelto de Task<ActionResult> a Task<FileResult>

domingo, 7 de junio de 2015

Buenas prácticas de programación:

Principios de diseño SOLID - Open/Closed (3/6)

En esta serie de buenas prácticas de programación ya hemos hablado del principio de responsabilidad única.

Aplicar los principios de diseño SOLID hará que podamos tener nuestro código mejor estructurado y que apliquemos Unit Tests de una mejor forma.

El segundo principio dentro de SOLID es el de "Abierto/Cerrado" (Open/Closed Principle). Este principio establece que cualquier entidad de SW (Clases, módulos, funciones) deben estar abiertas para extensión pero cerradas para modificaciones. Aunque suena a alguna contradicción, no lo es, debemos estructurar nuestros diseños para que al agregar funcionalidad modifiquemos lo mínimo nuestro código.  Debemos evitar que al modificar una clase tengamos que expandir esa modificación a las distintas clases de la aplicación.

Una de las formas más sencillas de escribir clases que que no tienen que cambiar es haciendo que cada clase haga únicamente una sola tarea (Aplicando el principio de Single Responsability),

Otra técnica que podemos utilizar es dividir nuestras tareas de acceso a datos y de lógica para mantenerlas en entidades distintas, de esa forma podemos cambiar una sin afectar a la otra.

El ejemplo que trataremos aquí es un caso de la vida real; En una de las empresas a las que llegué a trabajar me encontré con fragmentos de código (regados en la solución de VS) muy parecidos a esto:


miércoles, 6 de mayo de 2015

Propiedades dinámicas en C# (ExpandoObject)

¿Alguna vez te has preguntado si se pueden agregar propiedades de forma dinámica (en tiempo de ejecución) a los objetos?

Si has trabajado con MVC seguramente te es familiar el objeto ViewBag, al cual podemos agregar propiedades de forma dinámica.

Para poder utilizar propiedades dinámicas en C#, vamos a unir dos componentes: el tipo de datos dynamic y la clase ExpandoObject.

Si quieres saber un poco más sobre el tipo de datos dynamic, puedes revisar éste post.

La clase ExpandoObject (System.Dynamic) fue lanzada en el framework 4.0 y en conjunto con el tipo de datos dynamic nos permite tener objetos a los cuales podemos agregar propiedades dinámicas.

Únicamente tenemos que crear una variable de tipo dynamic e inicializarla como ExpandoObject, eso nos permitirá agregar propiedades dinámicas y poder consultarlas después.

Para crear cada propiedad, únicamente tenemos que asignarle un valor:


martes, 28 de abril de 2015

Diferencias entre tipos de datos var y dynamic en C#

Tal vez has visto en ejemplos de código, en internet o incluso en el código de algún compañero en tu empresa que se declaran variables var o incluso dynamic, ¿cuál es la diferencia entre var y dynamic?.

Si tenemos que dividir los lenguajes de programación de acuerdo a los tipos de datos que manejan podríamos establecer 2 grandes categorías:

-Tipos de datos dinámicos: Los tipos de datos dinámicos no se verifican en tiempo de compilación y hacen la verificación del tipo de variable en tiempo de ejecución, por ejemplo JavaScript.
-Tipos de datos estáticos: Los tipos de datos estáticos son tipos de datos predefinidos (int, string, bool, struct) y la verificación del tipo de variable se realiza al compilar el código, por ejemplo Java y C#.

Veamos las características de var y dynamic.

var

Pueden declararse variables var en lugar de declararse como un tipo específico (por ejemplo int o string). El compilador infiere el tipo de variable; es decir, podemos declarar una variable como var llamada varEjemplo y asignarle un valor de "lambdaBox.blogspot.com", el compilador determinará que es un tipo de datos string, eso nos evita tener que declarar el tipo de datos en cada declaración de variables.

Nota: Es importante remarcar que var no es un tipo de dato, es más bien un auxiliar al momento de declarar variables.


jueves, 22 de enero de 2015

Buenas prácticas de programación:

Principios de diseño SOLID - Single Responsability (2/6)

El primer principio corresponde a la 'S' y es el de Única Responsabilidad [Single Responsability Principle].

Éste principio establece que no debe de haber más de una responsabilidad (razón para cambiar) en una clase.

Para representar un ejemplo de la vida real podemos tomar las navajas suizas, donde en un solo objeto encontramos múltiples herramientas, eso hace que si debemos reemplazar una sola de las herramientas tengamos que desensamblar todas las demás herramientas. 




En cambio, si tenemos cada una de las herramientas por separado, podemos darle mantenimiento a cada una de las herramientas sin afectar el funcionamiento del resto de las herramientas.







Ahora podemos ver un ejemplo en código, supongamos que tenemos el siguiente código:
































martes, 20 de enero de 2015

Buenas prácticas de programación:

Principios de diseño SOLID - Introducción (1/6)

¿Qué es SOLID?

SOLID es un término que representa 5 principios básicos del diseño y programación orientada a objetos. La finalidad es crear código fácil de mantener, usar, escalar y probar. Debemos mencionar que SOLID es la guía y no el destino.




Esta entrada solo es la introducción al término, el detalle de cada uno de los principios tendrá una entrada aparte con ejemplos de código.

Los 5 principios SOLID son:
S [SRP] - Single Responsibility Principle: Cada objeto debe tener una única funcionalidad.
O [OCP] - Open/Closed Principle: Las clases deben estar cerradas a la modificación de la funcionalidad.
L [LSP] - Liskov Substitution Principle: Los Objetos pueden ser sustituidos con instancias de subtipos.
I [ISP] - Interface Segregation Principle: Las interfaces deben tener la mínima funcionalidad posible.
D [DIP] - Dependency Inversion Principle: Los objetos de alto nivel deben ser abstraidos de los objetos de bajo nivel.

Aplica los principios SOLID y tu código podrá ser administrado más facilmente, aumentando el ciclo de vida.

lunes, 1 de abril de 2013

Serialización XML de objetos en .net con C#

De acuerdo a wikipedia tenemos que la serialización:

"(En un contexto de almacenamiento de datos y comunicación) La serialización es el proceso de transformar el estado de una estructura de datos u objeto en un formato que pueda ser almacenado (por ejemplo en un archivo o transmitido a través de una red de datos) y restaurado posteriormente ya sea en otro o en el mismo entorno. La serie de bits resultantes pueden usarse para crear un objeto que es clon idéntico del original."

En resumen podríamos tener que la serialización y deserealización es el proceso por el cual se convierte un objeto en una secuencia linear de bytes y que pueden ser almacenados o transmitidos para posteriormente convertir esa secuencia de bytes en un objeto copia del original que almacena incluso su estado interno.

Es por eso que podríamos decir que si queremos almacenar un objeto en un archivo tenemos que almacenar lo que tengamos como resultado de la serialización.

El proceso de serialización es también conocido como deflating o marshall y el proceso contrario como inflating o  también se conoce como unmarshall.

Nuestro ejemplo de serialización consistirá de una clase "Automovil" que tendrá los siguientes atributos:
-Marca
-Modelo
-Año de fabricación
-Dirección hidráulica
-Automático
-Placas
-Numero de Cilindros
-Numero de puertas
-Color

Uno de los requisitos necesarios para poder serializar un objeto es que debemos marcarlo con el atributo [Serializable]