patrones de diseÑo

PATRONES DE DISEÑO

“Los patrones de diseño son el esqueleto de las soluciones a problemas comunes en el desarrollo de software.”

“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 siquiera dos veces de la misma forma”.

PATRÓN DE DISEÑO

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 interfaces

Son soluciones simples y elegantes a problemas específicos y comunes del diseño orientado a objetos.

UTILIDAD DE LOS PATRONES DE DISEÑO Documentar mecanismos simples que

funcionan Proveer un vocabulario y una

taxonomía comunes para desarrolladores y arquitectos de soluciones

Permitir que las soluciones sean descritas de manera concisa como una combinación de patrones

Facilitar la reutilización de las decisiones de arquitectura, diseño e implementación

OBJETIVOS DE LOS PATRONESLos patrones de diseño PRETENDEN:

Proporcionar elementos reusables en el diseño de sistemas software.

Evitar la reiteración en la búsqueda de soluciones a problemas ya solucionados anteriormente.

Formalizar un vocabulario común entre diseñadores.

Estandarizar el modo en que se realiza el diseño.

Facilitar el aprendizaje de las nuevas generaciones de diseñadores condensando conocimiento ya existente.

OBJETIVOS DE LOS PATRONESLos patrones de diseño NO PRETENDEN:

Imponer ciertas alternativas de diseño frente a otras.

Eliminar la creatividad inherente al proceso de diseño.

No es obligatorio utilizar los patrones, solo es aconsejable en el caso de tener el mismo problema o similar que soluciona el patrón.

Abusar o forzar el uso de los patrones puede ser un error.

CLASIFICACION DE LOS PATRONES

Patrones Creacionales: Inicialización y configuración de objetos.

Patrones Estructurales: Separan la interfaz de la implementación. Se ocupan de cómo las clases y objetos se agrupan, para formar estructuras más grandes.

Patrones de Comportamiento: Más que describir objetos o clases, describen la comunicación entre ellos.


Los patrones de creación abstraen la forma en la que se crean los objetos, permitiendo tratar las clases a crear de forma genérica dejando para más tarde la decisión de qué clases crear o cómo crearlas.

Según donde se tome dicha decisión podemos clasificar a los patrones de creación en patrones de creación de clase (la decisión se toma en los constructores de las clases y usan la herencia para determinar la creación de las instancias) y patrones de creación de objeto (se modifica la clase desde el objeto).

Patrones Creacionales:


Fábrica Abstracta: El problema a solucionar por este patrón es el de crear diferentes familias de objetos, como por ejemplo la creación de interfaces gráficas de distintos tipos (ventana, menú, botón, etc.).

Prototipado: Se basa en la clonación de ejemplares copiándolos de un prototipo.



Singleton : Restringe la instanciación de una clase o valor de un tipo a un solo objeto.

MVC: Este patrón plantea la separación del problema en tres capas: la capa model, que representa la realidad; la capa controler , que conoce los métodos y atributos del modelo, recibe y realiza lo que el usuario quiere hacer; y la capa vista, que muestra un aspecto del modelo y es utilizada por la capa anterior para interaccionar con el usuario.



Tratan de conseguir que cambios en los requisitos de la aplicación no ocasionen cambios en las relaciones entre los objetos. Lo fundamental son las relaciones de uso entre los objetos, y, éstas están determinadas por las interfaces que soportan los objetos. Estudian como se relacionan los objetos en tiempo de ejecución. Sirven para diseñar las interconexiones entre los objetos.

Patrones Estructurales:


Adaptador: Convierte una interfaz en otra.

Puente: Desacopla una abstracción de su implementación permitiendo modificarlas independientemente.

Objeto Compuesto: Utilizado para construir objetos complejos a partir de otros más simples, utilizando para ello la composición recursiva y una estructura de árbol.



Envoltorio: Permite añadir dinámicamente funcionalidad a una clase existente, evitando heredar sucesivas clases para incorporar la nueva funcionalidad.

Fachada: Permite simplificar la interfaz para un subsistema.

Peso Ligero: Elimina la redundancia o la reduce cuando tenemos gran cantidad de objetos con información idéntica.

Apoderado: Un objeto se aproxima a otro.



Los patrones de comportamiento estudian las relaciones entre llamadas entre los diferentes objetos, normalmente ligados con la dimensión temporal.

Patrones de Comportamiento:


Cadena de responsabilidad: La base es permitir que más de un objeto tenga la posibilidad de atender una petición.

Orden: Encapsula una petición como un objeto dando la posibilidad de “deshacer” la petición.

Intérprete: Intérprete de lenguaje para una gramática simple y sencilla.

Iterador : Define una interfaz que declara los métodos necesarios para acceder secuencialmente a una colección de objetos sin exponer su estructura interna.



Mediador: Coordina las relaciones entre sus asociados. Permite la interacción de varios objetos, sin generar acoples fuertes en esas relaciones.

Recuerdo: Almacena el estado de un objeto y lo restaura posteriormente.

Observador: Notificaciones de cambios de estado de un objeto



Estado: Se utiliza cuando el comportamiento de un objeto cambia dependiendo del estado del mismo.

Estrategia: Utilizado para manejar la selección de un algoritmo.

Método plantilla: Algoritmo con varios pasos suministrados por una clase derivada.

Visitante: Operaciones aplicadas a elementos de una estructura de objetos heterogénea.


CONCEPCIÓN DE PATRON DE DISEÑO SEGÚN MICROSOFT

Las columnas de la tabla son enfoques o puntos de vista de la solución y las filas representan los niveles de abstracción

ANTIPATRONES

Los patrones nos ofrecen una forma de resolver un problema típico, los antipatrones nos enseñan formas de enfrentarse a problemas con consecuencias negativas conocidas.

Los antipatrones se basan en la idea de que puede resultar más fácil detectar a priori fallos en el desarrollo del proyecto que elegir el camino correcto, o lo que es lo mismo, descartar las alternativas incorrectas nos puede ayudar a la elección de la mejor alternativa.

CLASIFICACION DE LOS ANTIPATRONES

ANTIPATRONES DE DESARROLLO:

-The blob (clases gigantes) -Lava flow (código muerto) -Functional Decomposition (Diseño No Orientado a Objetos) -Poltergeists (No se sabe lo que hacen algunas clases) -Golden Hammer (Para un martillo todo son clavos) -Spaghetti Code (Muchos if o switch)

-Cut & Paste programming (cortar y pegar código)


Antipatrones de arquitectura de software:

-Stovepipe enterprise (Aislamiento en la empresa, Islas de Automatización o Empresa con sistemas parcheados). La causa suele estar en una falta de estrategia tecnológica en la empresa, falta de cooperación y comunicación entre departamentos y niveles, deficiencias en el

conocimiento de la tecnología, etc. -Stovepipe system (Legacy System, Sistema Heredado, Aislamiento entre sistemas o Sistema Parcheado) -Vendor Lock-In (Arquitectura dependiente del producto, Amarrado por el vendedor, Esclavitud y Sumisión)


Antipatrones de arquitectura de software:

-Architecture by implication (Arquitectura Implícita). No se especifica

la arquitectura del sistema o ignora alguno de sus apartados.

-Design by committee (Diseño por Comité, Navaja suiza, Chapa de Oro, Enfermedad de Estandarización) Se da cuando el proyecto se diseña a través de las reuniones de un comité demasiado numeroso o inexperto. -Reinvent the wheel Se supone que se debe desarrollar desde cero, falta información y tecnología reusable entre proyectos


Antipatrones de gestión de proyectos:-Analysis paralysis. Ocurre cuando un equipo de analistas comienza una fase de análisis que sólo acaba cuando se cancela el proyecto.-Death by planning-Corncob (Personas problematicas) -Irrational management

-Project mismanegement

PATRONES DE INTERACCIÓN PARA ELDISEÑO DE INTERFACES WEB

Es muy frecuente encontrar interfaces para el WEB en las que no se considero que el usuario no es en la mayoría de los casos un experto en computación, sino que la aplicación puede ser usada por un publico diverso, que puede incluir personas con características especiales, al parecer es fácil olvidar que es el usuario quien determina el éxito o fracaso de una aplicación de software.

Problemática


Existen una gran cantidad de guías, pautas, estándares y reglas ergonómicas para diseñar interfaces usables, generalmente no es fácil aplicarlas en virtud de que no se precisa el escenario bajo el cual puedan aplicarse, no se conocen las consecuencias de su uso y no se tienen ejemplos específicos de cómo emplearlas a diferencia de los Patrones de Interacción en donde sí se especifica claramente como deben aplicarse, bajo que contexto y que implicaciones tiene su uso.

Propuesta


Un patrón tiene un formato bien definido, sus atributos frecuentes son: nombre del patrón, problema que resuelve, solución propuesta, contexto, ejemplos etc. Los patrones están estrechamente relacionados unos con otros y para un mejor aprovechamiento de estos no deben aplicarse de manera aislada.

PATRONES - INTERFACES WEB

La estructura de los patrones de la colección de Van Wellie es en términos generales la siguiente:

Nombre : El título del patrón, el cual debe serrepresentativo, claro y conciso del concepto a comunicar.

Autor: Quien propone al patrón. Problema : Una descripción del problema

desde el punto de vista del usuario. Principio de usabilidad: Describe los

principios ocriterios de usabilidad en los cuales se basa el patrón.

Contexto: Una descripción de la situación en la cual puede usarse el patrón, cuales son las características del contexto, en términos de las tareas, del usuario.


Fuerza: Aspectos del contexto

que necesitan ser optimizados. Solución: Descripción clara de

la solución propuesta(otros patrones pueden ser necesarios para completar la solución completa del problema)

Consecuencias: Describe los resultados de aplicar elpatrón.


Nombre: Formatos de Datos

de fechas Autor: Martijn Van Wellie Problema: El usuario desea

introducir datos de fechas y no desea preocuparse por la sintaxis del dato.

Principio: Guiar al usuario y prevenir errores

Ejemplo: Un ejemplo ilustrativo de una solución exitosa.


Contexto: Todos los sistemas que

requieran que el usuario introduzca fechas

Fuerzas: Los datos de fechas tienen múltiples sintaxis.

Solución: Permitir que el usuario elija la fecha de un calendario como en el mundo real.

Ejemplo:

LOS PELIGROS DE LOS PATRONES DE DISEÑO Un mal uso de los patrones de diseño y

en especial su uso cuando no es necesario pueden alargar considerablemente los plazos de desarrollo y hacer fracasar un proyecto.

De nada vale utilizar patrones de diseño si nadie los comprende en un equipo de desarrolladores ya que se crearán sistemas inmanejables y se crearán dependencias en los proyectos.

LOS PELIGROS DE LOS PATRONES DE DISEÑO Los diseños "artísticos" son siempre un

problema y deben ser evitados a toda costa.

El desarrollo es una labor de equipo. De nada sirven las grandes individualidades si el equipo es incapaz de aprovecharlas.

Aún así, los patrones de diseño son una herramienta imprescindible por todas las ventajas que nos aportan, demasiadas como para renunciar a ellos. Si nuestro equipo no domina los patrones de diseño hemos de tratar de ir incorporando poco a poco su conocimiento a base de formación continuada.

CONCLUSIÓN

Los patrones de diseño son una herramienta de gran valor para el desarrollo de software en general.

Actualmente, los patrones de diseño son sin duda alguna la herramienta más importante de la que disponemos los ingenieros, arquitectos, analistas, desarrolladores, etc., para la creación de sistemas robustos, escalables, fácilmente adaptables y con grandes cotas de reutilización.

patrones de diseÑo

Documents