Luis Baigorria – Software Developer

Acquire Wisdom and Live with Passion

Archive for the ‘Arquitecturas’ Category

Primeros avances del proyecto ASM

leave a comment »

Saludos a todos.

Hace varios días que inicie el desarrollo del proyecto ASM – Agentes Salvavidas de Mascotas, he aquí los primeros avances del proyecto (v0.1.0) para que puedas tener una idea del estado actual. Ya sabes, si quieres ser parte de este proyecto y colaborar en cualquiera de las partes, puedes escribirme en Facebook o pasarme un mensaje directo en en Twitter @uialberto

estadoasm

Recordarte que el proyecto es totalmente #opensource y se encuentra alojado en GitHub, cuando desees puedes darte una vuelta y ver el estado actual de avance.

Una vez finalizado el desarrollo de todos los issues de la versión 0.1.0, prepararé un vídeo en mi canal de #Youtube o un hangouts para comentarte sobre los componentes usados y la experiencia del mismo.

Saludos

 

Written by Luis Alberto

25/02/2017 at 7:55 PM

Proyecto Agente Salvavidas de Mascotas – ASM OpenSource

leave a comment »

Hola a todos.

Como lo había comentado hace un par de semanas atrás en la página de Facebook. Quiero y deseo crear una aplicación web para gestionar el proceso de publicación y adopción de mascotas. Será un proyecto de código abierto y le he puesto por nombre “ASM – Agente Salvavidas de Mascotas”. La idea principal es crear una comunidad de personas dispuestas a salvar y mejorar la calidad de vida de mascotas abandonadas en las calles o puestas en adopción, ofreciéndoles esta herramienta para facilitar y gestionar el proceso de encontrarles un hogar.

00001

¿Quieres ser parte del proyecto?

El proyecto estará escrito usando tecnología Microsoft .NET con C# 6.0 como lenguaje de programación, NET Framework 4.6.1, inicialmente con ASP.NET Web API como Framework de Servicios, etc.

He creado el repositorio en GitHub con la solución en blanco.

Características:

  • Gestionar Mascotas para Adopción
  • Gestionar Candidados de Adopción de Mascotas
  • Gestionar Estados de Publicación de Mascotas
  • Arquitectura del proyecto Domain Driven Design
  • Patrones de diseño Unidad de Trabajo, Repositorio, Inversión de Control e Inyección de Dependencias, Dtos, etc.
  • Autenticación Web API 2 OAuth Bearer Tokens
  • API REST bajo ASP.NET Web API 2
  • Entity Framework con Code First
  • Seguridad de Usuarios con ASP.NET Identity (Por definir)
  • Implementación de Pruebas Unitarias
  • Repositorio de Codigo GitHub

Como pueden ver, inicialmente el proyecto será creado como servicio usando ASP.NET Web API como Back-End. Espero que sea un proyecto de utilidad y sirva como base para futuros proyectos.

00002

En los próximos días estaré compartiendo y actualizando las primeras actividades a desarrollar en el proyecto en el Tablero de trabajo de GitHub

De igual manera, si encuentras errores en el proyecto, o tienes algunos comentarios / sugerencias puedes enviarlas al área de Issues de GitHub, o al correo: uialberto@outlook.com

Saludos y hasta pronto!

Written by Luis Alberto

05/01/2017 at 1:13 AM

01Principio de Responsabilidad Simple – SOLID

leave a comment »

Saludos.

Iniciamos una serie de publicaciones sobre los principios SOLID. Los principios S.O.L.I.D. son un conjunto de diseños y buenas prácticas que se emplean en OOD y OOP (diseño y programación orientada a objetos). Estos principios fueron desarrollados y publicados por primera vez por Robert “Tío Bob” Martin hace más de una década. En esta oportunidad detallaremos el primero de los principios, el Principio de Responsabilidad Simple. Este principio nos dice:

“There should never be more than one reason for a class to change”

“No debe existir mas que una sola razón para que una clase cambie”

El punto es que todos los atributos y todas las operaciones de una clase deben estar intrínsecamente relacionados con un solo propósito. Si se encuentra que al modificar una clase tiene dos responsabilidades se debe separar en dos clases respectivamente. Una clase que hace muchas cosas, es muy grande o muy complicada de seguro tendrá mas de una sola responsabilidad.

Para comprender mejor este principio vamos a ejemplificar mediante un diseño de clases.

Diagrama Clases - Violación al Principio de Responsabilidad Simple

Diagrama Clases – Violación al Principio de Responsabilidad Simple

 

El anterior diagrama muestra la violación del principio de responsabilidad simple ya que vemos que la clase Cuenta tiene más de una responsabilidad, esto se lo puede verificar mediante el método Transferir. Si bien tiene sentido que podamos transferir dinero de una cuenta a otra, vemos que se viola este principio al darle la responsabilidad a la clase Cuenta para dicho propósito. Esta operación debe ser sacada de la clase y llevada a otra que podemos  llamar por ejemplo ServicioTransferencia, así nuestra clase Cuenta solo tendría operaciones relacionadas a ella misma.

Veamos como seria una posible solución a la violación del Principio de Responsabilidad Simple.

Solución a Violación al Principio de Responsabilidad Simple

Solución a Violación al Principio de Responsabilidad Simple

 

Mediante este nuevo diseño podemos verificar la única responsabilidad para cada clase. Se ha delegado la responsabilidad a la clase ServicioTransferencia de Transferir dinero de una cuenta origen a una cuenta destino.

Ventajas de Aplicar este principio

  • Código más fácil de escribir y de entender.
  • Menos propenso a errores, ya que cada clase tiene una única responsabilidad bien definida
  • Facilita las tareas de testing : tenemos bien definido que debemos testear en cada clase.
  • Facilita las tareas de mantenimientos
  • Hace que nuestro código sea más robusto y extensible.

Espero les sea de utilidad.

 

 

Written by Luis Alberto

19/08/2013 at 8:47 PM

02 Principio de Abierto/Cerrado – SOLID

leave a comment »

Saludos.

Volviendo con las publicaciones de los principios SOLID, hoy veremos el Principio de Abierto/Cerrado (OCP).

Todas las aplicaciones cambian durante su ciclo de vida, ya sea esta por nuevos requerimientos, alguna mala identificación de los requerimientos o por el simple hecho que el cliente así lo requiera. Este principio nos ayuda a estar preparados para estas posibles situaciones, evitando así y reduciendo el impacto a futuros cambios.

El Principio Open/Closed (Open/Closed Principle, OCP) fue presentado por el Dr. Bertrand Meyer en su libro “Object Oriented Software Construction” y afirma que:

Software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification.

“Las entidades del software (clases, módulos, funciones, etc.) deben estar abiertas para la extensión pero cerrados para la modificación”

 Para comprender mejor este principio vamos a ejemplificarlo por medio de un diseño.

Diagrama clases – Explicación del Principio Abierto/Cerrado

Diagrama clases – Explicación del Principio Abierto/Cerrado

El diagrama anterior es un ejemplo de una clase que rompe con el principio abierto/cerrado (OCP). Vamos a suponer un sistema de gestión de proyectos, de tal manera nos vamos a centrar en la entidad Tarea y vamos a descubrir como rompe con el principio abierto/cerrado.

Como se puede observar en las relaciones dicha clase viene determinando por uno de los estados de la enumeración EstadoTarea (Pendiente, Finalizada, Cancelada), además se puede observar que la clase implementa 3 métodos, Iniciar, Cancelar y Finalizar que cambian si es posible el estado de la tarea. Veamos como sería una posible implementación del método Finalizar.

Violación al Principio de Abierto/Cerrado

Violación al Principio de Abierto/Cerrado

Al parecer esta implementación no esta nada mal, de hecho no esta nada mal si no se agregarán nuevos estados :), pero como comentamos al inicio, “todas las aplicaciones cambian durante su ciclo de vida”.

Supongamos entonces un nuevo requerimiento o cambio típico solicitado por el cliente de la aplicación, el cual sería la adición de un nuevo estado para controlar las tareas que se han Propuesto, con lo que la implementación de este método podría ser:

Violación al Principio de Abierto/Cerrado

Violación al Principio de Abierto/Cerrado

Aparentemente, parece una modificación trivial pero este cambio puede involucrar muchos otros, en los métodos y/o clases donde se utilice la enum EstadoTarea, no olvidemos que este nuevo cambio nos haría modificar también la implementación del método Cancelar.

Violación al Principio de Abierto/Cerrado

Violación al Principio de Abierto/Cerrado

Vemos claramente, por cada nuevo estado que implementemos tendremos que identificar la implementación para todas las clases que lo utilizan y modificarlas, violando el principio Abierto/Cerrado (OCP).

A continuación planteamos una solución a la violación del principio utilizando el patrón State.

Solución a violación del Principio Abierto/Cerrado

Solución a violación del Principio Abierto/Cerrado

Básicamente, lo que se ha hecho es crear una clase por cada estado en lugar de tener una única clase cuyos métodos están basados en sentencias condicionadas por el estado de la tarea. Además, con esta nueva implementación se ha delegado la responsabilidad de finalizar, cancelar o posponer a una nueva clase BaseEstadoTarea que que se ha marcado como abstracta. La clase Tarea implementará sus propios métodos y delegará la responsabilidad a través de las clases TareasEstados que heredan de BaseEstadoTarea. Debido a que la clase Tarea gira en torno a un estado, asumimos que el estado inicial por defecto es Pendiente, y así se deberá especificar en el constructor, instanciando a TareaEstadoPendiente.

Vamos a ver como seria la implementación para esta solución.

Implementación de la Solución con el patrón State

Implementación de la Solución con el patrón State

Ante un nuevo requisito en el que intervenga un nuevo estado, lo único que se deberá hacer es crear una nueva clase que herede de BaseEstadoTarea e implementar los métodos virtuales, extendiendo así el comportamiento de la aplicación sin comprometer el código existente.

Espero le sea de utilidad.

Articulo extraido de http://www.programacion.com
 
 

Written by Luis Alberto

17/08/2013 at 8:59 PM

03 Principio de Sustitución de Liskov – SOLID

leave a comment »

Saludos.

Volviendo con las publicaciones de los principios SOLID. Hoy veremos el Principio de Sustitución de Liskov (LSP).

Si bien existen varios ejemplos en la web en la que podemos comprender de que trata este principio, me he quedado con este por ser un caso real en la que se puede presentar.

Revisemos el enunciado de Robert C. Martin.

“Functions that use pointers or references to base classes must be able to use objects of derived classes without knowing it.” — Robert C. Martin

“Las funciones que utilicen punteros o referencias a clases base deben ser capaces de usar objetos de clases derivadas de éstas sin saberlo.”

Aún no quedo claro. ¿Verdad?

Si has comprendido el enunciado en tu primera lectura y no es necesario una explicación mas detallada al respecto, entonces eres genial. 🙂

 Pero existen varias definiciones al respecto, aquí algunas de ellas:

  1. Cada clase que hereda de otra puede usarse como su padre sin necesidad de conocer las diferencias entre ellas.
  2. Toda subclase debe soportar ser sustituida por su clase base lo que en términos de contratos significa que las precondiciones de los métodos de la subclase no serán más fuertes que las de la clase base, y sus pos condiciones no serán más débiles (en términos criollo: los métodos derivados no deben esperar más ni proveer menos que los originales).
  3. Las clases derivadas deben ser utilizables a través de la interfaz de la clase base, sin necesidad de que el usuario conozca la diferencia.

Claramente nos describen la importancia con respecto a crear clases derivadas y que estas deben ser tratadas como la clase base, es decir cuando creamos clases derivadas, hay que asegurarse de no reimplementar métodos que hagan que los métodos de la clase base no funcionen bien si al crear un objeto de la clase derivada se tratase como si fuera de la clase base. Para que se comprenda mejor, veamos el siguiente diagrama.

Principio de Substitución de Liskov

Diagrama clases – Explicación del Principio de Substitución de Liskov

Problemas:

Problema que rompre el 3er Principio SOLID

Violación al Principio de Substitución de Liskov

Tenemos un claro caso de violación del LSP con respecto a la definición 1, ya que la ejecución del método CalcularImpuesto generará una excepción de conversión de tipo si el objeto pasado por parámetro es de tipo Ciclomotor en lugar de Coche, pese a que ambas clases derivan de la misma clase base Vehículo.

Violación al Principio de Substitución de Liskov

Violación al Principio de Substitución de Liskov

Pese a que el compilador no genere ninguna excepción de conversión de tipo, esta clase aún viola el LSP. Esto es debido a que estamos forzando a un objeto Vehículo pasado como parámetro a comportarse como Ciclomotor o Coche.

Solución:

Solución a Violación del Principio de Sustitucion de Liskov

Solución a Violación del Principio de Sustitucion de Liskov

Agregamos un método virtual a la clase Vehiculo CalcularImpuesto que será reimplementado de acuerdo a la lógica requerida en cada una de las clases derivadas, así cuando la clase Impuesto requiera el cálculo en cada una de ellas pueda llamar al método implementado.

Implementación de la Solución a violación del LSP

Implementación de la Solución a violación del LSP

 

Es posible aplicar otras soluciones a este problema por medio del uso de interfaces, pero esto lo dejamos para futuras publicaciones.

Que sea de utilidad.

Hasta pronto.

Written by Luis Alberto

30/07/2013 at 11:29 PM

04 Principio de Segregación de Interfaces – SOLID

leave a comment »

Saludos.

Después  de mucho tiempo de ausencia en el Blog, hoy continuamos con los principios SOLID. En esta oportunidad quiere recordarle la importancia del Principio de Segregación de Interfaces. Fué introducido por el propio Robert Martin, veamos su definición:

Clients should not be forced to depend upon interfaces that they do not use.

Clientes no deben ser forzados a depender de interfaces que no usen.

Para una mejor comprensión se muestra a continuación un diagrama en el cual se tiene el problema del 4to principio SOLID.

11-07-2013 23-41-10

Problema que rompe el 4to principio SOLID

 

Problema: Como podemos ver en el diagrama de clases. Se tiene una interfaz IProceso que define las firmas: Iniciar, Suspender, Reiniciar, Finalizar para todo proceso. Así mismo tenemos una clase ProcesoManual y ProcesoAutomatizado que implementa la interfaz IProceso. Aquí vemos claramente como se rompe el 4to principio SOLID, ya que no debería existir implementacion de los métodos Reiniciar y Finalizar de la clase ProcesoAutomatizado ya que todo proceso automatizado no se reinicia ni finaliza su actividad. Entonces rompemos la regla: Clientes no deben ser forzados a depender de interfaces que no usen.

Para esto se debería aplicar la siguiente solución.

12-07-2013 0-05-48

Solución Aplicando el 4to Principio SOLID

 

La clase ProcesoAutomatizado solo implementa la interfaz IProceso, ya que mencionamos anteriormente no debería conocer ni implementar las firmas de la interfaz IManual, siendo que esta interfaz solo va ser implementada por ProcesoManual.

Con esto vemos que las clases cliente no implementa interfaz o firmas de la interfaz que no sean necesarias para su implemetación.

Que sea de ayuda para ti.

Saludos.

 

Written by Luis Alberto

12/07/2013 at 12:21 AM

05 Principio de Inversión de Dependencia – SOLID

with one comment

Saludos.

Hace un par de semanas acordamos con un grupo de amigos el de realizar una serie de presentaciones en el que cada uno buscaría un tema en particular y expondría el mismo para todos. Si bien no tenemos una fecha oficial para la realización del mismo, ya tengo lista mi presentación. Algunos temas a tratar: Programación con Silverlight, Servicios Web, Team Foundation Server y Principio Inversión de Dependencia. Una buena iniciativa para compartir conocimiento.

Principio Inversión de Dependencia. No es una presentación con efectos visuales elegantes, pero si trato de enfatizar y puntualizar los conceptos más importantes dentro de lo que es SOLID.

View this document on Scribd

Espero le sea de utilidad.

Hasta pronto.

Written by Luis Alberto

30/04/2013 at 12:05 AM

Publicado en Arquitecturas, DDD, Microsoft, SOLID

A %d blogueros les gusta esto: