PATRONES GOF

Está divido en tres partes y cada una describe los patrones relacionados con el tema de esa parte. Los temas describen el propósito de los patrones. Los patrones de creación se relacionan con problemas de instanciación de objetos. Los patrones estructurales se concentran en la composición de los objetos y sus relaciones con la estructura de los objetos en tiempo de ejecución. Mientras que los patrones estructurales describen la distribución del sistema de objetos, los patrones de comportamiento se enfocan en la dinámica interna e interacción de los objetos en el sistema.

PATRONES GRASP

PATRONES GRASP

En diseño orienteado a objetos  GRASP son patrones generales de software para asignación de responsabilidades, es el acronimo
de "General Responsability Assignment Software Patterns" . Aunque se considera que más que patrones propiamente dichos, son una serie de "buenas prácticas" de aplicación recomendable en el diseño de software.

EXPERTO EN INFORMACION

El GRASP de experto en información es el principio básico de asignación de responsabilidades. Nos indica, por ejemplo, que la responsabilidad de la creación de un objeto o la implementación de un método, debe recaer sobre la clase que conoce toda la información necesaria para crearlo. De este modo obtendremos un diseño con mayor cohesión y así la información se mantiene encapsulada (disminución del acoplamiento)
Problema: ¿Cuál es el principio general para asignar responsabilidades a los objetos?

Solución: Asignar una responsabilidad al experto en información.

Beneficios: Se mantiene el encapsulamiento, los objetos utilizan su propia información para llevar a cabo sus tareas. Se distribuye el comportamiento entre las clases que contienen la información requerida. Son más fáciles de entender y mantener

CREADOR

El patrón creador nos ayuda a identificar quién debe ser el responsable de la creación (o instanciacion ) de nuevosobejetos o clases.
La nueva instancia deberá ser creada por la clase que:

• Tiene la información necesaria para realizar la creación del objeto, o
• Usa directamente las instancias creadas del objeto, o
• Almacena o maneja varias instancias de la clase
• Contiene o agrega la clase.

Una de las consecuencias de usar este patron es la visibilidad entre la clase creada y la clase creador. Una ventaja es el bajo acoplamiento, lo cual supone facilidad de mantenimiento y reutilizacion La creación de instancias es una de las actividades más comunes en un sistema orientado a objetos. En consecuencia es útil contar con un principio general para la asignación de las responsabilidades de creación. Si se asignan bien el diseño puede soportar un bajo acoplamiento, mayor claridad, encapsulación y reutilización.

CONTROLADOR

El patrón controlador es un patrón que sirve como intermediario entre una determinada interfaz y el algoritmo que la implementa, de tal forma que es la que recibe los datos del usuario y la que los envía a las distintas clases según el método llamado.
Este patrón sugiere que la lógica de negocios debe estar separada de la capa de presentación, esto para aumentar la reutilización de código y a la vez tener un mayor control.
Se recomienda dividir los eventos del sistema en el mayor número de controladores para poder aumentar la cohesion y disminuir el acoplamiento.

ALTA COHESION Y BAJO ACOPLAMIENTO

Los conceptos de cohesión y acoplamiento están íntimamente relacionados. Un mayor grado de cohesión implica uno menor de acoplamiento. Maximizar el nivel de cohesión intramodular en todo el sistema resulta en una minimización del acoplamiento intermodular.

ALTA COHESION

Nos dice que la información que almacena una clase debe de ser coherente y debe estar (en la medida de lo posible) relacionada con la clase.
1. Cohesión Coincidente: El módulo realiza múltiples tareas, sin ninguna relación entre ellas.
2. Cohesión Lógica: El módulo realiza múltiples tareas relacionadas, pero, en tiempo de ejecución, sólo una de ellas será llevada a cabo.
3. Cohesión Temporal: Las tareas llevadas a cabo por un módulo tienen, como única relación el deber ser ejecutadas “al mismo tiempo”.
4. Cohesión de Procedimiento: La única relación que guardan las tareas de un módulo es que corresponden a una secuencia de pasos propia del “producto”.
5. Cohesión de Comunicación: Las tareas corresponden a una secuencia de pasos propia del “producto” y todas afectan a los mismos datos.
6. Cohesión de Información: Las tareas llevadas a cabo por un módulo tienen su propio punto de arranque, su codificación independiente y trabajan sobre los mismos datos. El ejemplo típico: OBJETOS
7. Cohesión Funcional: Cuando el módulo ejecuta una y sólo una tarea, teniendo un único objetivo a cumplir, se dice que tiene Cohesividad Funcional.



BAJO ACOPLAMIENTO

Es la idea de tener las clases lo menos ligadas entre sí que se pueda. De tal forma que en caso de producirse una modificación en alguna de ellas, se tenga la mínima repercusión posible en el resto de clases, potenciando la reutilización, y disminuyendo la dependencia entre las clases
1. Acoplamiento de Contenido: Cuando un módulo referencia directamente el contenido de otro módulo. (En lenguajes de alto nivel es muy raro)
2. Acoplamiento Común: Cuando dos módulos acceden (y afectan) a un mismo valor global.
3. Acoplamiento de Control: Cuando un módulo le envía a otro un elemento de control que determina la lógica de ejecución del mismo.

PATRONES DE CONTROL

 COMPONENTES DE LOS PATRONES DE CONTROL DE AUTOMATIZACION DE LA                   INTERFAZ DE USUARIO

Los patrones de control admiten los métodos, las propiedades, los eventos y las relaciones que son necesarios para definir una parte discreta de la funcionalidad que está disponible en un control.

• La relación entre un elemento de Automatización de la interfaz de usuario y su elemento primario, sus elementos secundarios y sus elementos relacionados describe la estructura del elemento en el árbol de Automatización de la interfaz de usuario.
• Los métodos permiten a los clientes de Automatización de la interfaz de usuario manipular el control.
• Las propiedades y los eventos proporcionan información acerca de la funcionalidad del patrón de control, así como información acerca del estado del control.

Los patrones de control se relacionan con la interfaz de usuario como las interfaces se relacionan con los objetos del Modelo de objetos componentes (COM).En COM, puede consultar un objeto para averiguar qué interfaces admite y, a continuación, usar esas interfaces para tener acceso a funcionalidad.En la Automatización de la interfaz de usuario, los clientes de Automatización de la interfaz de usuario pueden preguntar a un control qué patrones de control admite y, a continuación, interactuar con el control a través de las propiedades, los métodos, los eventos y las estructuras expuestos por los patrones de control admitidos.Por ejemplo, para un cuadro de edición de varias líneas, los proveedores de Automatización de la interfaz de usuario implementan ISCROLLPROVIDER .Cuando un cliente sabe que AUTOMATIONELEMENT admite el patrón de control SCROLLPATTERN puede usar las propiedades, los métodos y los eventos expuestos por ese patrón de control para manipular el control o tener acceso a información sobre el mismo.

PROVEDORES Y CLIENTES DE AUTOMATIZACION DE LA INTERFAZ DE USUARIO

Los proveedores de Automatización de la interfaz de usuario implementan patrones de control para exponer el comportamiento adecuado de una parte específica de la funcionalidad que admite el control.
Los clientes de Automatización de la interfaz de usuario obtienen acceso a los métodos y las propiedades de las clases de patrones de control de Automatización de la interfaz de usuario y los usan para obtener información acerca de la interfaz de usuario o para manipular la interfaz de usuario.Estas clases de patrones de control se encuentran en el espacio de nombres System.Windows.Automation (por ejemplo,Invokepattern y SelectionPattern.
Los clientes usan métodos AutomationElement.(como       AutomationElement.GetCurrentPropertyValue oAutomationElement.GetCachedPropertyValue ) o descriptores de acceso de common language runtime (CLR) para tener acceso a las propiedades de Automatización de la interfaz de usuario en un patrón.Cada clase de patrón de control tiene un miembro de campo (por ejemplo,InvokePattern.Pattern o SeletionPattern.Pattern ) que identifica a ese patrón de control y se puede pasar como parámetro a GetCachedPattern o GetCurrentPattern a fin de recuperar ese patrón para un AutomationElement.

PATRONES DE DISEÑO

Algunos controles no siempre admiten el mismo conjunto de patrones de control.Se considera que se admiten los patrones de control cuando están disponibles para un cliente de Automatización de la interfaz de usuario.Por ejemplo, un cuadro de edición de varias líneas habilita el desplazamiento vertical sólo cuando contiene más líneas de texto de las que se pueden mostrar en su área visible.El desplazamiento se deshabilita cuando se quita texto suficiente y ya no es necesario desplazarse.En este ejemplo, el patrón de control ScrollPattern se admite dinámicamente en función del estado actual del control (cuánto texto hay en el cuadro de edición).

PATRON " MODELO VISTA-CONTROLADOR"

Patrón "Modelo-Vista-Controlador"

Para el diseño de aplicaciones con sofisticados interfaces se utiliza el patrón de diseño Modelo-Vista-Controlador. La lógica de un interfaz de usuario cambia con más frecuencia que los almacenes de datos y la lógica de negocio. Si realizamos un diseño ofuscado, es decir, un pastiche que mezcle los componentes de interfaz y de negocio, entonces la consecuencia será que, cuando necesitemos cambiar el interfaz, tendremos que modificar trabajosamente los componentes de negocio. Mayor trabajo y más riesgo de error.

Se trata de realizar un diseño que desacople la vista del modelo, con la finalidad de mejorar la reusabilidad. De esta forma las modificaciones en las vistas impactan en menor medida en la lógica de negocio o de datos.

Elementos del patrón:

• Modelo: datos y reglas de negocio
• Vista: muestra la información del modelo al usuario
• Controlador: gestiona las entradas del usuario

Un modelo puede tener diversas vistas, cada una con su correspondiente controlador. Un ejemplo clásico es el de la información de una base de datos, que se puede presentar de diversas formas: diagrama de tarta, de barras, tabular, etc. Veamos cada componente:

1. El modelo es el responsable de:
   • Acceder a la capa de almacenamiento de datos. Lo ideal es que el modelo sea independiente del sistema de almacenamiento.
   • Define las reglas de negocio (la funcionalidad del sistema). Un ejemplo de regla puede ser: "Si la mercancía pedida no está en el almacén, consultar el tiempo de entrega estándar del proveedor".
   • Lleva un registro de las vistas y controladores del sistema.
   • Si estamos ante un modelo activo, notificará a las vistas los cambios que en los datos pueda producir un agente externo (por ejemplo, un fichero bath que actualiza los datos, un temporizador que desencadena una inserción, etc).
   
   
2. El controlador es responsable de:
   • Recibe los eventos de entrada (un clic, un cambio en un campo de texto, etc.).
   • Contiene reglas de gestión de eventos, del tipo "SI Evento Z, entonces Acción W". Estas acciones pueden suponer peticiones al modelo o a las vistas. Una de estas peticiones a las vistas puede ser una llamada al método "Actualizar()". Una petición al modelo puede ser "Obtener_tiempo_de_entrega( nueva_orden_de_venta )".
   
   
3. Las vistas son responsables de:
   • Recibir datos del modelo y los muestra al usuario.
   • Tienen un registro de su controlador asociado (normalmente porque además lo instancia).
   • Pueden dar el servicio de "Actualización()", para que sea invocado por el controlador o por el modelo (cuando es un modelo activo que informa de los cambios en los datos producidos por otros agentes).

 

 

PATRONES DE DISEÑO

Los PATRONES DE DISEÑO son la base para la busqueda de soluciones a problemas comunes en el desarrollo del software y otros ambitos referentes al diseño de interaccion o interfacez.

Un patron diseño es una solucion a un problema de diseño para que una solucion sea considerada un patron debe poseer ciertas caracteristicas. Una de ellas es que debe haber comprobado su EFECTIVIDAD resolviendo problemas similares en ocasiones anteriores. Otra es que debe ser REUSABLE lo que significa que es aplicable a diferentes problemas de diseño en distintas circunstacias.

los patrones de diseño pretenden

• Proporcionar catalogos de elementos reusables en el diseño de sistemas de software.
• Evitar la reiteracion en la busqueda de soluciones a problemas ya conocidos y solucionados anteriormente.
• Formalizar un vocabulario comun 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.

Los patrones no pretenden:

• Imponer ciertas alternativas frente a otras.
• Eliminar la creatividad inherente al proceso de diseño.