Code Refactoring Videos

Continuando con el tema de refactorización de codigo aqui os dejo otro excelente curso de 18 videos, publicado en YouTube por Derek Banas.
How to write great code that is easy to modify & understand

Listado de todos los videos:

1. How to write great code that is easy to modify & understand, Part I

2. How to write great code that is easy to modify & understand, Part II

3. Using variables to write understandable code

4. Extracting methods, fields, classes and eclipse shortcuts

5. Replacing constructors with Factory Methods and more

6. Simplifying Condicional and Polymorphism

7. Replacing Conditionals with Strategy Pattern

8. Eliminate duplicate code with the Template Method

9. Replace implied primitive trees with the Composite Pattern

10. Revisiting the Builder Desing Pattern

11. Builiding a composite with the Builder Pattern

12. Eliminate large accumulation methods by Extracting Methods

13. Replace conditionals with Command Pattern

14. How and When to use the Adapter Pattern

15. Replace primitives with a class / Improve Type Safety

16. How to move embellishments using the Decorator Pattern

17. Adding functionality with the Visitor Pattern

18. Review of Abstract Factory Pattern

Todos los videos estan en Ingles. Recomendandos 100%

Introduccion a TDD y Refactoring

Colección de 8 Videos de Autentia de las Charlas realizadas en 2012 sobre TDD, refactoring, calidad del código y como detectar malos olores en el código fuente de los proyectos, donde nos explica de forma fácil y bastante clara una serie de principios y factores clave que todo desarrollador Senior debería conocer y aplicar en su día a día.

TDD y Refactoring Video


Listado de todos los videos

TDD y Refactoring Video 1/8

TDD y Refactoring Video 2/8

TDD y Refactoring Video 3/8

TDD y Refactoring Video 4/8

TDD y Refactoring Video 5/8

TDD y Refactoring Video 6/8

TDD y Refactoring Video 7/8

TDD y Refactoring Video 8/8

Todos los videos estan en castellano. Recomendado 100%.

Desacoplamiento n-capas, patron IoC, DI y SOLID

Aqui teneis este excelente video de Hadi Hariri realizado en el XXV Foro de Arquitectos celebrado en Microsoft Ibérica de Madrid sobre el Desacoplamiento entre componentes de arquitecturas n-capas: IoC & DI.

Los puntos tratados son:

  • Principios SOLID
  • Desacoplamiento de las tecnologías-infraestructura
  • Importancia de las Pruebas Unitarias
  • Mocking
  • Introducción a Unity
  • Mapeo a Arquitectura N-Layer

Las siglas IoC y DI significan:

Las siglas SOLID son un acrónimo de :

  • Single Responsibility Principle: Una clase solo debe tener una única responsabilidad o propósito.
  • Open/Closed Principle: Una clase debe esta abierta para ser extendida, pero cerrada para ser modificada. (os suenan las clases abstractas).
  • Liskov Substitution Principle: Las clases derivadas deberían poder ser sustituibles por sus clases base.
  • Interface Segregation Principle: Nos propone utilizar interfaces para modelar las clases y dotarlas de funcionalidad y  no usar clases con interfaces que no son necesarias.
  • Dependency Inversion Principle:  Las abstracciones no deben depender de los detalles, los detalles deben depender de las abstracciones. Es decir, los módulos de más alto nivel no deben depender de los de más bajo nivel sino que ambos deben depender de abstracciones. (Os suena el patrón IoC)

Podeis ver el video online o descargarlo en este link: video IoC-DI

Arquitectura SOA (Services Oriented Architecture)

La Arquitectura SOA o Arquitectura Orientada a Servicios, es un concepto de arquitectura de software que define la utilización de servicios para dar soporte a los requisitos del negocio. Permite la creación de sistemas altamente escalables que reflejan el negocio de la organización, a su vez brinda una forma estándar de exposición e invocación de Servicios Web, lo cual facilita la interacción entre diferentes sistemas propios o de terceros.

Esta definición se hace mediante los estándares que engloban los WebServices (WS) y seguramente todos conoceis, como son XML, SOAP, WSDL, UDDI, DISCO.

Aspectos Básicos de SOA

En la arquitectura SOA la funcionalidad deseada se descompone en unidades (servicios) que pueden ser distribuidos en diferentes nodos conectados a través de una red y que, asimismo, son combinados entre sí para alcanzar el resultado deseado. Estos servicios pueden proporcionar datos a otros o llevar a cabo actividades de coordinación entre uno o varios servicios.

Esta arquitectura presenta un modelo de construcción de sistemas distribuidos donde la funcionalidad demandada será entregada a la aplicación a través de servicios. En la siguiente figura se muestra el esquema de la arquitectura y los elementos que podrían observarse. Como puede observarse, el esquema se encuentra dividido en 2 zonas; una que abarca el ámbito funcional de la arquitectura y otra vinculada a la calidad de servicio.

En definitiva, en la actualidad hablar de arquitectura de software es hablar de SOA. Pero hablar de SOA no es hablar sólo de web services, sino que el tema va mucho más allá. El ciclo de vida de desarrollo de software, desde el diseño hasta la operación, está encima de la mesa para ser re-estudiado en base a las aportaciones y posibilidades de SOA. A medida que el mercado vaya adoptando las estrategias y tecnologías implicadas, veremos madurar el desarrollo de software hasta niveles no alcanzados por el momento. El mundo del software no deja de reinventarse contínuamente. Tenemos entre manos una nueva generación de ideas, vamos a ver hasta dónde nos llevan.

Si queremos ampliar información consultar este documento de MS sobre la arquitectura SOA aplicada al mundo (real-world-SOA) donde se detallan casos reales de uso.

También teneis esta blog de arquitectura SOA, que no os podeis perder.

Patrones y Antipatrones de diseño

Para seguir profundizando un poco más con el tema de ingenieria de software y patrones de diseño, aqui teneis un fantastico artículo que explica perfectamente los conceptos de patrones y antipatrones de diseño.

“Los patrones de software facilitan la reutilización del diseño y de la arquitectura, capturando las estructuras estáticas y dinámicas de colaboración de soluciones exitosas a problemas que surgen al construir aplicaciones.”

“Los antipatrones son soluciones negativas que presentan más problemas que los que solucionan. Son una extensión natural a los patrones de diseño. Comprender los antipatrones provee el conocimiento para intentar evitarlos o recuperarse de ellos. El estudio de los antipatrones permite conocer los errores más comunes relacionados con la industria del software. La obra de referencia en este campo es AntiPatterns: Refactoring Software, Architectures and Projects in Crisis

La imagen muestra una comparación entre patrones y antipatrones:

Bb972251.art235-img03-568x360(es-es,MSDN.10).jpg

Artículo completo:

Patrones y Antipatrones: Parte I

Patrones y Antipatrones: Parte II

Patrones de Fabricación de Objetos

Continuando con los patrones de diseño, en este artículo de Microsoft analizan los patrones de fabricación más conocidos, con muchos ejemplos y código fuente, para hacermos una visión  detallada del mecanismo de funcionamiento.

Llamamos patrones de fabricación a aquellos patrones que involucran algún tipo de factoría o fábrica (factory, en inglés) de objetos. Estos patrones entran en la categoría de patrones de creación, la cual comparten con otros patrones tales como el Singleton, Builder y Prototype.

Los objetos de fabricación (fábricas) tienen la responsabilidad de crear instancias de objetos de otras clases. Tienen además la responsabilidad y el conocimiento necesario para encapsular la forma en que se crean determinados tipos de objetos en una aplicación.

Existen diferentes patrones de fabricación. En este artículo, trataremos Abstract Factory, Factory Method, y Simple Factory. Los dos primeros están incluidos en el catálogo del GoF y serán tratados en mayor profundidad.

En la imagen se muestra los diferentes tipos de factorías. En cada caso, cada cuadro representa una clase y cada línea es un método en esa clase:

Bb972258.art251-img01-425x400(es-es,MSDN.10).jpg

Ejemplos de tipos de fábricas de objetos.

Contenido del articulo completo:

1. Introducción
1.1. Fábricas
1.2. Factory Method vs. Creation Methods
1.3. Relación entre los Patrones de Factoría
2. Factory Method
2.1. Definición del Patrón
2.2. Breve Discusión
2.3. Ejemplo “No Software”
2.4. Ejemplos en .net Framework
2.5. Ejemplos de Código
2.5.1. Variaciones de Factory Method
2.5.1.1. Creador es una Clase Abstracta o Interface
2.5.1.2. Creador es una Clase Concreta con Implementación Predeterminada
2.5.1.3. Métodos de Fabricación Parametrizados
2.5.1.4. Lazy Initialization
2.5.1.5. Combinación de Factory Method y Template Method
3. Abstract Factory
3.1. Definición del Patrón
3.2. Breve Discusión
3.3. Factory Method y Abstract Factory
3.4. Ejemplo “No Software”
3.5. Ejemplos en .net
3.6. Ejemplo de Código
4. Factory Pattern (Simple Factory)
4.1. Ejemplos de Código
4.2. ¿Por qué estas Clases no se engloban en los Patrones Anteriores?
4.2.1. Simple Factory y Factory Method
4.2.2. Simple Factory y Abstract Factory
5. Conclusión: Flexibilidad y Complejidad
Referencias y Bibliografía

Si quereis saber más, aqui esta el articulo completo escrito por León Welicki, la verdad interesantisimo.

Que son los Patrones de Diseño / Design Patterns

¿Qué es un Patrón de Diseño o Design Pattern?

Según Microsoft:  “Los patrones de diseño son el esqueleto de soluciones a problemas comunes en el desarrollo de software.”

Según Wikipedia: “Los patrones de diseño son la base para la búsqueda de soluciones a problemas comunes en el desarrollo de software y otros ámbitos referentes al diseño de interacción o interfaces.”

En otras palabras, son soluciones probadas y documentadas basadas en la experiencia a problemas de desarrollo de software que están sujetos a contextos similares y que se ha demostrado que funcionan.

 

Un poco de historia nunca viene mal

El origen de los patrones, vienen del mundo de la construcción, donde un arquitecto llamado Christopher Alexander llegó a la siguiente conclusión mientras planificaba edificios, que muchos procesos del diseño y la construcción se repetian en el tiempo.

Exactamente, Christopher Alexander da la siguiente definición de patrón: “Cada patrón describe un problema que ocurre una y otra vez en nuestro entorno, para describir después el núcleo de la solución a ese problema, de tal manera que esa solución pueda ser usada más de un millón de veces sin hacerlo ni siquiera dos veces de la misma forma”.

Resumiendo: Un problema que se repite en el tiempo, tiene por consiguiente una solución que se repite de igual manera.

En base a estos conceptos, en la decada de los 90s, un grupo de estudiosos del software y la POO , conocidos como GoF (Gang of Four), adaptaron estos conceptos para aplicarlos al diseño y desarrollo de software, publicando el libro más famoso y conocido sobre patrones, Design Patterns: Elements of Reusable Object-Oriented Software, que consta de 23 patrones y dieron un vuelto en el mundo de la construcción del software.
¿Para qué sirve un Patrón de Diseño?

Esta es la pregunta clave, entender para que sirve un patrón de diseño, antes hemos dicho que los patrones nos dan una solución a problemas comunes en el desarrollo de software, pero !!Que carajo quiere decir esto!!.

Simplemente esto, los patrones nos muestran como declarar y definir nuestras interfaces, clases y objetos para resolver un problema en el desarrollo de nuestras aplicaciones y es tarea del arquitecto / desarrollador,  conocer todos los patrones de diseño y tomar la decisión de saber cuales utilizar y los que mejor se adaptan a los requerimientos de nuestra aplicación.

Por otro lado, si vemos en nuestra aplicación los patrones de diseño utilizados podemos de un vistazo entender el problema que teniamos y la solución adoptada sin tener que investigar y debugear por el código hasta entender todo el proceso.

Asi que, toca empollarse sí o sí, todos los patrones de diseño más comunes que podais, si buscais por Internet vereis que existen muchos más patrones especializados de los que teneis en la lista, que también es importante conocer.

Patrones de Diseño más comunes

Antes de nada, es importante conocer a los que se consideran los padres o fundadores de los patrones de diseño, llamados comunmente Gang of Four (GoF) autores del famoso libro Design Patterns.

Los elementos básicos de un patrón de diseño son:

  • Su nombre (veremos los nombres mas abajo).
  • El problema (cuando aplicar un patrón para solucionar un problema de software).
  • La solución (descripción abstracta del problema).
  • Las consecuencias (costos y beneficios de usar patrones).

Existen 3 Categorias de patrones de diseño:

  • Patrones Creacionales: Inicialización y configuración de objetos.
  • Patrones Estructurales: Separan la interfaz de la implementación.
  • Patrones de Comportamiento:  Describen la comunicación entre objetos o clases.

En la web de DoFactory están explicados en ingles, todos estos patrones, con código fuente en .Net para los más atrevidos, aqui teneis todos los enlaces y los patrones con su nombre y descripción:

Creational Patterns
Abstract Factory Creates an instance of several families of classes
Builder Separates object construction from its representation
Factory Method Creates an instance of several derived classes
Prototype A fully initialized instance to be copied or cloned
Singleton A class of which only a single instance can exist
Structural Patterns
Adapter Match interfaces of different classes
Bridge Separates an object’s interface from its implementation
Composite A tree structure of simple and composite objects
Decorator Add responsibilities to objects dynamically
Facade A single class that represents an entire subsystem
Flyweight A fine-grained instance used for efficient sharing
Proxy An object representing another object
Behavioral Patterns
Chain of Resp. A way of passing a request between a chain of objects
Command Encapsulate a command request as an object
Interpreter A way to include language elements in a program
Iterator Sequentially access the elements of a collection
Mediator Defines simplified communication between classes
Memento Capture and restore an object’s internal state
Observer A way of notifying change to a number of classes
State Alter an object’s behavior when its state changes
Strategy Encapsulates an algorithm inside a class
Template Method Defer the exact steps of an algorithm to a subclass
Visitor Defines a new operation to a class without change

Espero, que con esta pequeña guía os aclare las dudas generales sobre lo que es un patrón de diseño. Si quereis saber más, podeis ampliar en el articulo completo de Patrones de Diseño de la web de Microsoft.