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>

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:

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.

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.

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]

Agregar controles a formularios de forma dinámica (por código o en tiempo de ejecución) en .net con C#

El editor de Visual Studio nos permite tener un gran control granular de la interfaz que tendrá nuestra aplicación winforms en cuanto al manejo de controles se refiere, sin embargo es muy conveniente saber cómo podemos agregar nuestros propios controles al formulario en tiempo de ejecución (en forma dinámica o mediante código).

Probablemente no lo consideren necesario, pero es algo realmente útil por ejemplo si quieres crear una lista de imágenes en miniatura que genera las miniaturas a partir de las imágenes que contenga un folder, en cuyo caso es muy dificil controlar la cantidad de PictureBox que tendrá tu formulario a menos que se generen dinámicamente en tiempo de ejecución.

Nuestro ejemplo será precisamente ese, un formulario que genere las miniaturas de las imágenes que se encuentran en un folder determinado.

Primeramente creamos nuestro proyecto de tipo "Windows Forms Application".

El siguiente paso es personalizar nuestro formulario. En este ejemplo se agregó:

Controles iniciales.

TextBox: para conocer el folder del cual se extraerán las imágenes, se le llamo txtBxFolder
Button: para crear el cuadro de diálogo que nos permite seleccionar un folder, se le llamo txtFolder
Button: para ejecutar la acción de obtener las imágenes, se le llamó btnObtenerImg.

Para poder desplegar las imágenes necesitamos controles de tipo PictureBox y los colocaremos sobre un control del tipo FlowLayoutPanel. La razón es para evitarnos el problema de ir colocando los controles uno tras otro y que su posicionamiento cambie de acuerdo al tamaño de nuestra ventana. Se debe aclarar que generalemte los controles que agregamos dinámicamente deben de tener las propiedades del lugar donde se colocaran dichos controles.

Agregamos el control del tipo FlowLayoutPanel y lo llamaremos PanelImgs, el formulario resultante queda así:

A continuación crearemos el cuadro de diálogo que nos permitirá elegir un folder dentro de nuestro sistema de archivos, para eso debemos controlar el evento clic de nuestro botón btnSelectFolder y agregamos el siguiente código:

Manejo de Formularios MDI con C# y Visual Studio 2010 Express

Antes de iniciar debemos aclarar que existen dos tipos de Formularios:
SDI (Single Document Interface)
MDI (Multiple Document Interface)

Los Formularios MDI son aquellos que permiten contener otros formularios dentro de ellos.

Para crear una aplicación de tipo MDI primeramente tenemos que crear nuestro proyecto (Aplicación de Windows).
En el formulario principal debemos establecer la propiedad IsMdiContainer a True.

Formulario Principal

Posteriormente debemos Crear el formulario base que será la plantilla que tendrán nuestros formularios child. En nuestro caso hemos tratado de simular un editor de texto bastante simple pero con soporte MDI.

Agregamos un nuevo formulario a nuestro proyecto.

Agregamos un primer panel en la parte inferior que podrá contener botones si así lo deseamos, para hacer eso establecemos la propiedad Dock del panel en Bottom.

Después agregamos un segundo panel que contendrá nuestro cuadro de texto y establecemos la propiedad Dock en Fill.

Agregamos nuestro textbox y lo renombramos a txtBoxContent y establecemos su propiedad Dock en Fill.

Agregamos un botón al panel de la parte inferior que sera la simulación de un botón que servirá para guardar nuestro documento. Con esto tendremos nuestro formulario base.

Formulario Base

Ahora crearemos un menú para tener una administración muy sencilla de las ventanas child (en el formulario Principal). Observemos que la opción "Lista ->"  no tiene subelementos ya que los crearemos en tiempo de ejecución

.

SecureString - Almacenar contraseñas en memoria de forma segura en .net.

En mi caso y espero que no sea su caso (por lo de la contraseña), al desarrollar las aplicaciones que se conectarán a una base de datos me gusta tener una clase que me administre la conexión a la Base de Datos y todos los campos que ésta necesita (incluyendo la contraseña de acceso).  Para evitar almacenar la contraseña en memoria en un tipo string podemos utilizar SecureString [System.Security.SecureString].

Uno de los puntos importantes es que SecureString implementa CriticalFinalizerObject, lo cual significa que SecureString se considera una Región de ejecución restringida (Constrained Ejecution Region - CER) lo que significa que las excepciones de tipo out-of-band estan prohibidas en regiones de tipo CER por lo que evitamos que cierta parte del código no se ejecute (con el fin de liberar de memoria el objeto SecureString llamando la función Dispose()). Se debe tener en cuenta que SecureString se mantiene en una región no administrada de la memoria, por lo que es nuestra responsabilidad liberar ese recurso.

Nota: Considera que no tiene caso almacenar una contraseña o cualquier dato sensible en un  string y pasarlo como parámetro para agregarlo a un objeto SecureString si no eliminamos de memoria ese string inmediatamente despues de utilizarlo.

Utilizar SecureString.

una de las formas en que podemos utilizar SecureString en combinación con las propiedades (get & set):

En mi caso marqué la propiedad get como privada para accesar únicamente desde la misma clase.

 Es importante volver a decir que no debemos almacenar permanentemente una copia de la contraseña en memoria.

Crear un Web Service básico con C# y Visual Studio Web Developer 2010 (Express)

Teniendo Visual Studio Web Developer 2010 (lo puedes descargar gratis de la página oficial de Microsoft) podemos desarrollar nuestros propios Web Services de una forma muy sencilla.

En el ejemplo mostrado corremos nuestro Web Service bajo nuestro propio servidor IIS en XP.

Si no tienes noción sobre los Web Services te recomiendo una ligera lectura con la que tendrás una mejor idea de lo que se trata.

Primeramente crearemos un nuevo sitio web, damos clic en el boton "Browse..."

Posteriormente seleccionamos "Local IIS", "Default Web Site", "Create new Web Application", le asignamos un nombre y damos clic en "Open".

Damos clic en el botón "OK" de la ventana New Web Site.






Creando el Web Service.

En nuestro Explorador de soluciones damos clic con el botón derecho en el Web Site y seleccionamos "Add New Item..."

¿Qué es un Web Service? - Introducción

Probablemente ya habrás escuchado hablar sobre los Servicios Web [Web Services], aquí intentaremos explicar brevemente y de una forma muy sencilla qué son esos Web Services.

Iniciaremos diciendo que los Web Services nos permiten la interoperabilidad entre dos dispositivos sobre una red mediante un esquema Cliente-Servidor.

Debido a que la comunicación es  con estándares XML los Web Services no dependen de ninguna plataforma, Sistema Operativo o Lenguaje de Programación; por lo que yo pudiera tener un cliente desarrollado en .net y corriendo bajo Windows XP y consumir un Web Service desarrollado en Java y corriendo bajo Linux, es por esa razón que los Web Services se utilizan ampliamente en el uso de "Sistemas Distribuidos".

La mayoría de los Web Services utiliza HTTP y HTPPS para poder transmitir mensajes (tanto de solicitud como de respuesta).

Actualmente las grandes empresas utilizan Web Services para poder establecer comunicación en un esquema Cliente-Servidor que permita la transmisión de objetos mediante la serialización XML, esto significa que transforman el Objeto en memoria a una versión XML que puede ser transmitido a través de HTTP y al recibir el mensaje XML se puede volver a instanciar un objeto con las características originales que se describieron en el mensaje XML.

SOAP es el protocolo base que define la forma en que se transmitirán los mensajes; está basado en XML.