Patrón Interpreter. Ejemplo Evaluador de Expresiones Notación Polaca Inversa

Patrón Interpreter:

 Ejemplo Evaluador de Expresiones en Notación Polaca Inversa

Este patrón es un caso especial de “Composite”, aplicado al parseo. El parseo transforma una entrada de texto en una estructura de datos (usualmente un árbol) que es apropiada para ser procesada. Generalmente los parseadores primero identifican los símbolos de la entrada y luego construyen el árbol de parseo para esos símbolos. 

Dado un lenguaje, el patrón “Interpreter” define una representación para su gramática y un intérprete para su lenguaje. Se emplea para definir un lenguaje para definir expresiones regulares que representen cadenas a buscar dentro de otras cadenas. Utiliza una clase para representar cada regla gramática.

En el mundo real, los lenguajes están formados por expresiones no terminales que contienen construcciones terminales dentro. Encontramos el patrón “Interpreter” a la hora de analizar esas expresiones.

Este patrón se debe utilizar cuando hay un lenguaje que interpretar y se puede interpretar sus palabras como árboles sintácticos abstractos. Para ello, la gramática debe ser simple.

Ejemplo de árbol sintáctico abstracto:

Árbol de sintaxis abstracta para el siguiente código del algoritmo de Euclides:

while b ≠ 0

if a > b

a := a − b

else

b := b − a

return a

Esquema UML del patrón:

AbstractExpression: declara una interfaz para la ejecución de una operación.
TerminalExpression: implementa una operación asociada con los símbolos terminales de la gramática
NonterminalExpression: implementa una operación de interpretación asociada con los símbolos no terminales de la gramática.
Context: contiene información global para el interprete.
Client: construye un árbol sintáctico abstracto que representa una sentencia particular en el lenguaje que la gramática define. El cliente construye una expresión

Ventajas:

• Facilidad para cambiar la gramática, mediante herencia, dado que las diferentes reglas se representan con objetos.
• Facilidad para implementar la gramática, dado que las implementaciones de las clases nodo del árbol sintáctico son similares, pudiendo usarse para ello generadores automáticos de código.
• Facilidad para introducir nuevas formas de “interpretar” las expresiones en la gramática.

Desventajas:

• Limitación en el tipo de gramática: si no es simple, es casi imposible implementarlo.
• No es conveniente utilizarlo si la eficiencia es un punto clave.

Ejemplo:  Evaluador de Expresiones. Ejemplo de la wikipedia ampliado
Se trata de evaluar expresiones matemáticas en notación polaca  inversa ( wikipedia  ). Vamos a tener encuenta las operaciones suma, resta, multiplicación y division. Ademas, si se produce algún error al analizar la expresión,  devolverá información sobre el, para que el usuario pueda modificar la expresion.
Proyecto:

Clase Expresion:
Va ha ser el interfase usado por las operaciones y numeros
->

Clase TerminalExpresion_Plus (operador suma)
->

Clase TerminalExpresion_Minus (operador resta )
->

Clase TerminalExpresion_Multi  (operador multiplicacion)
->
Clase TerminalExpresion _Div (operador  divisor)
->

Clase TerminalExpresion_Number (numero decimal)
->

Clase Parser:
Se encarga de recibir la expresion, construir el arbol y evaluar dicho arbol retornando informacion del valor o error producido
->

Clase Fmain: Programa principal
Formulario en pantalla, que rellenar el textbox con una expresion y pulsar el boton "Evaluar", se encarga de mostrar la información.
->

Captura de la aplicación ejecutandose:

Enlace de Descarga: enlace



Fuentes:
http://es.wikipedia.org/wiki/Interpreter_(patr%C3%B3n_de_dise%C3%B1o)
http://www.godtic.com/blog/2012/11/15/patrones-de-diseno-gof/
http://migranitodejava.blogspot.com.es/search/label/Interpreter
http://www.oodesign.com/interpreter-pattern.html
http://ldc.usb.ve/~mgoncalves/IS2/sd07/grupo6.pdf
http://www.blackwasp.co.uk/Interpreter.aspx
http://sourcemaking.com/design_patterns/interpreter/cpp/1

Patrón Singleton: Ejemplo: Creando Log

Patrón Singleton:

 Ejemplo: creando log

El Patrón Singleton también se conoce como Instancia única, su objetivo es restringir la creación de objetos  pertenecientes a una clase, de modo que solo se tenga una única instancia de la clase para toda la aplicación, garantizando así un punto de acceso global al objeto creado.

Como observareis, en Gambas3, ya tenemos implementado ese patrón con el uso de los módulos (module).
Incluso, si lo queremos aplicar a una clase, usaríamos la orden Create Static, para convertirla en clase tipo Singleton.

Este patrón es  muy útil cuando necesitamos crear un clase común y global para todo el sistema.

Ejemplo:
Vamos a crear una aplicación que haga un log (un registro) de las acciones de los usuarios en los formularios (pulsar botones). Para ello usaremos una clase singleton (ClaseLogSingleton) que será la encargada de almacenar lo que hagan los usuarios.

Proyecto

Clase ClaseLogSingleton:


Clase PersonaVo:


Clase Main:


Clase (formulario) VentanaPrincipal

Clase (formulario) VentanaEventos:


Clase (formulario) VentanaLog:


Ejemplo de la aplicación:

enlace de descarga del ejemplo completo: enlace de descarga

Fuentes:
http://codejavu.blogspot.com.es/2013/07/ejemplo-patron-singleton.html
Documentación: http://gambasdoc.org/help/lang/createstatic?es&v3

Patrón Iterator: Ejemplo: Recorrer una lista de diversas formas

Patrón Iterator

 Ejemplo: 

Recorrer una lista de diversas formas

El objetivo principal de este patrón es la manipulación de datos mediante los indices de una estructura ya sea estática (Arrays) o dinámica (Listas). la condición de este patrón es que el acceso debe de ser secuencial mente, a continuación se mencionan algunas de las operaciones que puede contener una clase iterador:

      -Recorridos uno a uno hacia delante.
      -Recorridos uno a uno hacia atras.
      -Recorridos en saltos.
      -Aplicación de Filtros.
      -Aplicación de operaciones.
      -Consulta de un dato por su posición.
      -etc..

Ejemplo:
Vamos a tener una lista (array) de cadenas de texto, y la vamos a mostrarla de diversas maneras:
1) Del elemento 0 hasta el final
2) Desde el final hasta el elemento 0
3) Solo los elementos que ocupen posiciones pares en el array
4) Solo los elementos, cuyas cadenas  contentan la letra "m"

Proyecto:

Clase: Iterador


Clase IteradorHaciaAdelante:


Clase IteradorHaciaAtras:


Clase IteradorPares


Clase IteradorContenidoCadena


Programa principal:


Programa ejecutándose:

Enlace del ejemplo:enlace a box


Fuentes:
http://ayudajoe.blogspot.com.es/2012/03/patron-de-diseno-iterador-java.html
http://jarroba.com/arraylist-en-java-ejemplos/
http://www.aprenderaprogramar.com/index.php?option=com_content&view=article&id=589:ejercicio-y-ejemplo-resuelto-interface-iterable-y-metodo-iterator-java-cu00912c&catid=58:curso-lenguaje-programacion-java-nivel-avanzado-i&Itemid=180

http://arantxa.ii.uam.es/~eguerra/docencia/0708/03%20Iterator.pdf

http://jahepi.blogspot.com.es/2007/09/patrn-iterador-actionscript-30.html -> varios tipos de iteradores

Patrón Memento: Ejemplo: Marcador de Futbol

Patrón Memento

Ejemplo: Marcador de Futbol

El patrón de comportamiento Memento, un modelo para capturar (parte o todo) y externalizar el estado interno de un objeto para restaurarlo más tarde sin violar el encapsulamiento. Puede ser usado  en combinación con los Patrones Command e Iterator. 

El patrón Memento es aplicable cuando: 

• Todo o parte del estado de un objeto debe ser guardado para ser restaurado más tarde. 
• Cuando una interfaz directa para obtener el estado de un objeto exponga detalles de su  implementación

Participantes 
· Memento.

• - Almacena el estado interno de un objeto Originator. El Memento puede almacenar mucho o parte del estado interno de Originator. 
• - Tiene dos interfaces. Una para Caretaker, que le permite manipular el Memento  únicamente para pasarlo a otros objetos. La otra interfaz sirve para que Originator pueda almacenar/restaurar su estado interno, sólo Originator puede acceder a esta interfaz, al menos en teoría. 

 · Originator.

• - Originator crea un objeto Memento conteniendo una fotografía de su estado interno. 
• - Originator usa a Memento para restaurar su estado interno. 

· Caretaker

• - Es responsable por mantener a salvo a Memento. 
• - No opera o examina el contenido de Memento

 Patrones relacionados
· Command: Puede usar “Mementos” para guardar el estado de operaciones restaurables.
· Iterator: “Mementos” puede ser usado con Iterator para buscar colecciones para estados específicos.

Ejemplo: Marcador de Fútbol
Se trata de realizar un marcador de fútbol, donde deberá aparecer:
-Resultado del 1º tiempo
-Resultado del 2º tiempo
-Resultado Final
-Nombre de Jugadores y minuto de cuando marca gol según el equipo.
Además se podrá deshacer y rehacer la introducción de resultados y jugadores.

Clases en el Proyecto:

Clase State:

Esta clase se encargará de almacenar los datos que nos interese del estado.

Clase Memento:

Clase Caretaker:

Programa Principal:

Captura de pantalla del programa en ejecucion:

Enlace de descarga: enlace a box

Enlaces:
http://www.slideshare.net/An3s/patron-memento
http://migranitodejava.blogspot.com.es/2011/06/memento.html
http://www.freewebz.com/amanecer/personal/papers/paper.memento.pdf

Patrón Adaptador: Ejemplo tipos de motor

 Patrón Adaptador: 

Ejemplo tipos de motor

Este patrón permite la cooperación entre clases para extender sus funcionalidades a clases de diferentes tipos, que no pueden usarlas por mecanismos comunes como la herencia. 

Permite trabajar juntas a dos clases con interfaces incompatibles:

 Convierte la interfaz de una clase en otra interfaz que el cliente espera. Esto permite a las clases trabajar juntas, lo que de otra manera no podrían hacerlo debido a sus interfaces incompatibles

Este patrón se debe utilizar cuando:

• Se quiere utilizar una clase que llame a un método a través de una interface, pero se busca utilizarlo con una clase que no implementa ese interface.
• Se busca determinar dinámicamente que métodos de otros objetos llama un objeto.
• No se quiere que el objeto llamado tenga conocimientos de la otra clase de objetos.

Diagrama UML patrón Adapter (Adaptador)

Target: define la interfaz específica del dominio que Cliente usa.
Client: colabora con la conformación de objetos para la interfaz Target.
Adaptee: define una interfaz existente que necesita adaptarse
Adapter: adapta la interfaz de Adaptee a la interfaz Target
El Cliente llama a las operaciones sobre una instancia Adapter. De hecho, el adaptador llama a las operaciones de Adaptee que llevan a cabo el pedido.



Ejemplo: Diversos tipos de motores
Queremos compartir funcionalidades (encender, acelerar y apagar), mediante la herencia creando una clase Motor,  entre estos tipos de motores: MotorComun, MotorEcologico y MotorElectrico.
Pero el MotorElectrico, se comporta de una manera muy diferente que los otros.
Para poderlo usar de la misma forma que los demás (con los mismos métodos), vamos a usar una clase adaptadora, que sirva de puente entre la clase padre "Motor" y la clase MotorElectrico, y que se encargue de traducir los métodos de la clase MotorElectrico a los métodos de clase "Motor" . Así el cliente podrá usar  los motores sin difirenciarlos.

Esquema del ejemplo:

http://codejavu.blogspot.com.es/2013/08/ejemplo-patron-adapter.html

Esquema del proyecto:

Clase Motor
->

Clase MotorComun
->

Clase MotorEconomico
->

Clase MotorElectrico
->

Clase MotorElectricoAdapter
Con esta clase, conseguimos adaptar el uso de la clase MotorElectrico con los métodos de la clase Motor
->

Clase Aplicacion:
->

Programa principal:
->

Resultado de la aplicación:

Enlace de descarga ejemplo: https://app.box.com/s/qflrvc7xtmalktjn4dge

Fuentes:
http://migranitodejava.blogspot.com.es/2011/06/adapter.html

http://codejavu.blogspot.com.es/2013/08/ejemplo-patron-adapter.html

http://pinbit.blogspot.com.es/2008/09/patrones-estructurales-i-patrn-adapter.html

Patrón Delegation. Ejemplo: Empleado de Tienda

Patrón  Delegation

 Ejemplo: Empleado de Tienda

Se trata de una técnica en la que un objeto permite mostrar cierto método al exterior, pero internamente la implementación o las acciones desencadenadas por el llamado de este método se delega a otro objeto de una clase distinta pero asociado. La delegación es utilizada como un mecanismo para centralizar en torno a un solo objeto  los compartimentos (métodos) de varios objetos donde dichos comportamientos mantienen cierto nivel de relación.

Utilidad:

• Cuando se quiere extender y reutilizar la funcionalidad de una clase sin utilizar la herencia.
• Alternativa a la herencia múltiple, en lenguajes que no la soportan.

Ventajas:

•  Cuando una clase que hereda de otra quiere ocultar algunos de los métodos heredados
•  Compartir código que NO se puede heredar

Con herencia Múltiple y Delegación: simulándola con herencia simple y composición

Nota:
Diferencia entre Herencia y Composición: 

• Herencia:  Debería modelar una relación es-un entre la clase derivada y la clase base.
• Composición: La relación que modela es un tiene-un y, en general, la composición debe preferirse a la herencia.

Ejemplo:
Tenemos la clase EmpleadoTienda, que es a su vez Persona y Empleado. Podemos representarlo mediante herencia múltiple y también, usando el patrón delegation, con herencia simple :

En gambas3, se haría usando el patrón delegation.

Proyecto:

Clase Trabajador:
->

Clase Persona
->

Clase  EmpleadoDeTienda
Esta clase va a ser herencia de Persona y ademas está compuesta por una objeto de la clase Trabajador. En ella hemos definidos los métodos que llamarán a los métodos de la clase trabajador.

Programa Principal:
->



Pantallazo de la aplicación:

Enlace de descarga del ejemplo: enlace


Fuentes:
http://codejavu.blogspot.com.es/2013/06/ejemplo-patron-delegate.html
 http://siul02.si.ehu.es/~alfredo/iso/06Patrones.pdf
http://es.wikipedia.org/wiki/C%2B%2B#Herencia_simple
http://ingeniods.wordpress.com/2013/09/11/delegation-patron-de-diseno/

Patrón Bridge: Ejemplo dibujando punteado y normal

Patrón Bridge: 

Ejemplo dibujando punteado y normal

Este patrón permite modificar las implementaciones de una abstracción en tiempo de ejecución. Básicamente es una técnica usada en programación para desacoplar la interface de una clase de su implementación, de manera que ambas puedan ser modificadas independientemente sin necesidad de alterar por ello la otra.

Este patrón debe ser utilizado cuando:

• Se desea evitar un enlace permanente entre la abstracción y su implementación. Esto puede ser debido a que la implementación debe ser seleccionada o cambiada en tiempo de ejecución.
• Tanto las abstracciones como sus implementaciones deben ser extensibles por medio de subclases. En este caso, el patrón Bridge permite combinar abstracciones e implementaciones diferentes y extenderlas independientemente.
• Cambios en la implementación de una abstracción no deben impactar en los clientes, es decir, su código no debe tener que ser recompilado.
• Se desea compartir una implementación entre múltiples y este hecho debe ser escondido a los clientes.
• Permite simplificar jerarquías demasiado pobladas.

Consecuencias

• Desacopla interface e implementación: una implementación no es limitada permanentemente a una interface. Le es posible a un objeto cambiar su implementación en tiempo de ejecución. Este desacoplamiento fomenta las capas, que pueden conducir a un sistema mejor estructurado.
• La parte de alto nivel de un sistema sólo tiene que conocer Abstraction e Implementor.
• Mejora la extensibilidad: se puede extender las jerarquías de Abstraction e Implementor independientemente.
• Esconde los detalles de la implementación a los clientes

Diagrama UML:

Abstraction: define una interface abstracta. Mantiene una referencia a un objeto de tipo Implementor.
RefinedAbstraction: extiende la interface definida por Abstraction
Implementor: define la interface para la implementación de clases. Esta interface no se tiene que corresponder exactamente con la interface de Abstraction; de hecho, las dos interfaces pueden ser bastante diferentes entre sí. Típicamente la interface Implementor provee sólo operaciones primitivas, y Abstraction define operaciones de alto nivel basadas en estas primitivas.
ImplementadorConcreto: implementa la interface de Implementor y define su implementación concreta.

Abstraction emite los pedidos de los clientes a su objeto Implementor. El cliente no tiene que conocer los detalles de la implementación.

Ejemplo:
Imaginemos que necesitamos dibujar distintas figuras geométricas (círculo, rectángulo, etc). Cada figura geométrica puede ser dibujada con diferentes tipos de líneas (normal, punteada, etc).
Vamos a combinar las clases de tal forma que tanto un Círculo como un Rectángulo sepan como dibujarse de manera abstracta, pero le dejaremos la implementación a un especialista en dibujo.

Esquema de clases:

Esquema del proyecto:

Partimos de las Clases especialistas en dibujar:
Clase Dibujo:
->

Clase DibujoNormal:
->


Clases DibujoPunteado:
->


Definimos la clase Forma, de donde heredan las de Circulo y Rectangulo.
Las clases Círculo y  Rectángulo sabrán como dibujarse pero de manera abstracta.
- Clase Forma
->

-Clase Circulo
->

-Clase Rectangulo
->

Programa principal:
->

Pantallazo de la aplicación ejecutándose:

Enlace de descarga del código fuente: enlace a box

fuente:
http://migranitodejava.blogspot.com.es/search/label/Bridge

Patrón Proxy: Ejemplo Realizar un control de acceso a recursos y/o partes del programa

Patrón Proxy

Ejemplo Realizar un control de acceso a recursos y/o partes del programa

El patrón Proxy se utiliza como intermediario para acceder a un objeto, permitiendo controlar el acceso a él. Para ello obliga que las llamadas a un objeto ocurran indirectamente a través de un objeto proxy, que actúa como un sustituto del objeto original, delegando luego las llamadas a los métodos de los objetos respectivos.

Este patrón se debe utilizar cuando:

• Se necesite retrasar el coste de crear e inicializar un objeto hasta que es realmente necesario.
• Se necesita una referencia a un objeto más flexible o sofisticada que un puntero.

Algunas situaciones comunes de aplicación son:

• Proxy remoto: representa un objeto en otro espacio de direcciones. Esto quiere decir que el proxy será utilizado de manera tal que la conexión con el objeto remoto se realice de forma controlada sin saturar el servidor.
• Proxy virtual: crea objetos costosos por encargo. Cuando se utiliza un software no siempre se cargan todas las opciones por default. Muchas veces se habilitan ciertos módulos sólo cuando el usuario decide utilizarlos.
• Proxy de protección: controla el acceso a un objeto. Controla derechos de acceso diferentes.
• Referencia inteligente: sustituto de un puntero que lleva a cabo operaciones adicionales cuando se accede a un objeto (ej. contar el número de referencias, cargar un objeto persistente en memoria, bloquear el objeto para impedir acceso concurrente, ...).

El patrón Proxy es muy versátil. Puede ser utilizado en infinitas ocasiones y se le puede otorgar varios usos. Tiene una gran ventaja y es que no obliga al desarrollador a crear demasiada estructura para realizar este patrón, sino que es una forma estándar de acceder a una clase que potencialmente puede ser conflictiva. Por otro lado, no ayuda al desarrollador a crear un algoritmo, sino que el desarrollador tiene que hacer toda la lógica.
Por estas razones, es un patrón donde no siempre se puede saber a priori cuando utilizarlo.

Esquema UML:

Subject: interfaz o clase abstracta que proporciona un acceso común al objeto real y su representante (proxy).
Proxy: mantiene una referencia al objeto real. Controla la creación y acceso a las operaciones del objeto real.
RealSubject: define el objeto real representado por el Proxy.
Cliente: solicita el servicio a través del Proxy y es éste quién se comunica con el RealSubject.

Esquema de Proxy usado para control de acceso a un recurso

Ejemplo: Control De Acceso A Recursos/Partes del Propgrama
Para enseñar como  se  usaría este patrón para realizar un control de acceso a distintos recursos, y ademas llevar un contador de cuantos intentos de accesos se han realizado y cuantos han accedido. (lo usaremos como  Proxy de protección  y Referencia inteligente )
 Tenemos 3 tipos de usuarios y dos departamentos (recursos), que tienen su acceso permitido segun este cuadro:

Esquema de interacción entre clases:

Este sería el proyeto en Gambas3:

Recursos:
Clase Irecurso:
->

Clase RecursoAlmacen:
->

Clase RecursoContabilidad:
->

Control mediante Proxy de los Recursos:
Clase RecursoProxy:
->

En esta clase, he definido la variable "hnivel" para el recurso, que con su valor se comprobará si puede acceder o no el usuario.


Clase RecursoAlmacenProxy:
->

Clase RecursoContabilidadProxy:
->

Clase Usuario:
->

Los usuarios, tienen una propiedad "nivelAcceso" que les  indica cual será su  nivel de acceso.
Es muy sencillo, gestionar el acceso a los usuarios a los distintos recursos, simplemente cambiando el valor de esta propiedad.

Programa Principal:
->



Ejecutando la aplicación en el IDE de Gambas3:

Podéis ver, como en la consola se va mostrando información de los intentos accesos de los usuarios .
 Estos datos se pueden guardar fácilmente en un archivo, no lo he querido añadir, para simplificar al máximo el ejemplo.


Enlace de descarga del ejemplo: enlace box

Fuentes:
http://arantxa.ii.uam.es/~eguerra/docencia/0809/12%20Proxy.pdf
http://migranitodejava.blogspot.com.es/search/label/Proxy

Patrón State: Ejemplos: Conexión/Desconexión y Ventanilla del Banco

Patrón State

Ejemplos:  Conexión/Desconexión y Ventanilla del Banco

Este patrón permite que un objeto modifique su comportamiento cada vez que cambie su estado interno. Busca que un objeto pueda reaccionar según su estado interno. Si bien muchas veces esto se puede solucionar con un boolean o utilizando constantes, esto suele terminar con una gran cantidad de if-else, código ilegible y dificultad en el mantenimiento. La intención del State es desacoplar el estado de la clase en cuestión.

En determinadas ocasiones se requiere que un objeto tenga diferentes comportamientos según el estado en que se encuentra. Esto resulta complicado de manejar, sobretodo cuando se debe tener en cuenta el cambio de comportamientos y estados de dicho objeto, todos dentro del mismo bloque de código. El patrón State propone una solución a esta complicación, creando un objeto por cada estado posible.

Este patrón debe ser utilizado cuando:

• El comportamiento de un objeto depende de un estado, y debe cambiar en tiempo de ejecución según el comportamiento del estado.
• Cuando las operaciones tienen largas sentencias con múltiples ramas que depende del estado del objeto.

 Este patrón se utiliza cuando un determinado objeto tiene diferentes estados y también distintas responsabilidades según el estado en que se encuentre en determinado instante. También puede utilizarse para simplificar casos en los que se tiene un complicado y extenso código de decisión que depende del estado del objeto.

Diferencias entre patrón State y Strategy:

El patrón State permite hacer diferentes cosas dependiendo del estado del objeto. En otras palabras, lo que cambia de acuerdo al estado es que se hace. Además, todas las posibilidades están incluidas en el código del modelo. A la hora de agregar nuevos estados y su correspondiente acción asociada basta con agregar una subclase sin tocar las demás (observando el Open-Close principle).
En cambio el patrón Strategy permite hacer lo mismo de diferentes maneras. En otras palabras, lo que cambia es como se hace. Este patrón usualmente permite que la implementación específica (la estrategia) se pueda seleccionar por configuración, por el estado de cierto objeto, etc.

Ejemplo:  Conexión y Desconexión
Tenemos una conexión la cual puede estar en dos estados: conectada  y desconectada

-Clase Conexion:
->

-Clase Conectado
->

-Clase Desconectado
->

-Programa principal:
->


Pantallazo en la ejecución:

Ejemplo: Ventanilla de Banco
Tenemos un banco y en el una ventanilla de atención al público.
Cuando llegamos, nos colocamos en la fila de la ventanilla.

•  Si la misma esta abierta, seguiremos en la fila.
•  En cambio, si esta cerrada nos colocaremos en otra fila o tomaremos alguna decisión acorde.
•  Por otro lado, si vemos un cartel que dice "Espere 5 minutos por favor..." quizás tenemos que contemplar el tiempo disponible que tenemos. 

 Es decir, para nosotros, el comportamiento de un banco cambia radicalmente según el estado en el que se encuentre.

Esquema del Banco, Ventanilla y estado de la Ventanilla.

Clase Ventanilla
->

Clase EstadoVentanilla
->

Clase Abierta
->

Clase Cerrada
->

Clase Suspendida
->

Clase Banco
->

Clase Persona
->

Programa principal:
->





Pantallazo en la ejecución:

Enlaces de descarga:
Ejemplo Conexion
Ejemplo Banco-Ventanilla


Fuentes:
http://migranitodejava.blogspot.com.es/2011/06/state.html
http://lcanaveral.com/ean/state.pdf
http://www.design-nation.net/es/archivos/001844.php
http://carlospeix.com/2011/04/cul-es-la-diferencia-entre-el-patrn-strategy-y-state/
http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf
http://r0d.developpez.com/articles/dp-state-es/

El patrón State aplicado al desarrollo de juegos
http://www.design-nation.net/es/archivos/001844.php

El patrón State aplicado al desarrollo de juegos ( II )
http://www.design-nation.net/es/archivos/001845.php

El patrón State aplicado al desarrollo de juegos ( III )
http://www.design-nation.net/es/archivos/001846.php

El patrón State aplicado al desarrollo de juegos ( IV y final )
http://www.design-nation.net/es/archivos/001856.php

Patrón Builder. Ejemplo: Creando Coches de Marca

Patrón Builder

Ejemplo: Creando Coches de Marca

Este patrón permite la creación de un objeto complejo, a partir de una variedad de partes que contribuyen individualmente a la creación y ensamblaje del objeto mencionado.
Centraliza el proceso de creación en un único punto, de tal forma que el mismo proceso de construcción pueda crear representaciones diferentes. (ver fuentes)

Se utiliza:
-Independizar el algoritmo de creación de un objeto complejo de las partes que constituyen el objeto y cómo se ensamblan entre ellas.
- Que el proceso de construcción permita distintas representaciones para el objeto construido, de manera dinámica.
- Este patrón debe utilizarse cuando el algoritmo para crear un objeto suele ser complejo e implica la interacción de otras partes independientes y una coordinación entre ellas para formar el ensamblaje.

Esquema:

Parte que lo forman:

• Producto: representa el objeto complejo a construir.
• Builder: especifica una interface abstracta para la creación de las partes del Producto. Declara las operaciones necesarias para crear las partes de un objeto concreto.
• ConcreteBuilder: implementa Builder y ensambla las partes que constituyen el objeto complejo.
• Director: construye un objeto usando la interfaz Builder. Sólo debería ser necesario especificar su tipo y así poder reutilizar el mismo proceso para distintos tipos.

El Cliente crea el objeto Director y lo configura con el objeto Builder deseado.
El Director notifica al constructor cuándo una parte del Producto se debe construir.
El Builder maneja los requerimientos desde el Director y agrega partes al producto.
El Cliente recupera el Producto desde el constructor.

 Consecuencias

• Permite variar la representación interna de un producto.
• El Builder ofrece una interfaz al Director para construir un producto y encapsula la representación interna del producto y cómo se juntan sus partes.
• Si se cambia la representación interna basta con crear otro Builder que respete la interfaz.
• Separa el código de construcción del de representación.
• Las clases que definen la representación interna del producto no aparecen en la interfaz del Builder.
• Cada ConcreteBuilder contiene el código para crear y juntar una clase específica de producto.
• Distintos Directores pueden usar un mismo ConcreteBuilder.
• Da mayor control en el proceso de construcción.
• Permite que el Director controle la construcción de un producto paso a paso.
• Sólo cuando el producto está acabado lo recupera el director del builder.

Ejemplo: (basado en el ejemplo de: Maximiliano Juarez 

Crear un objeto Auto, este sería nuestro producto. El auto se compondrá de varios atributos que lo componen: motor, marca, modelo y cantidad de puertas.

Esquema del proyecto:


Clase Auto:
->

Clase Motor:
->

Clase AutoBuilder:
El Builder (AutoBuilder) define al menos dos cosas: un método para devolver el Producto (el auto en nuestro caso) y los métodos necesarios para la construcción del mismo.
->

Clase FiatBuilder
->

Clase FordBuilder
->

Clase AutoDirector:
Lo primero que debe hacerse con esta clase es enviarle el tipo de auto que se busca construir (Ford, Fiat, etc). Luego, al llamar al método constructAuto(), la construcción se realizará de manera automática.
->


Programa principal:
->



Aplicación ejecutándose:

Enlace de descarga del ejemplo: enlace


Fuentes:
http://migranitodejava.blogspot.com.es/search/label/Builder
http://informaticapc.com/patrones-de-diseno/builder.php
http://sourcemaking.com/design_patterns/builder

Patrón Facade (fachada): Ejemplo de Inmobiliaria

Patrón de Fachada: 

Ejemplo de Inmobiliaria

Busca simplificar el sistema, desde el punto de vista del cliente, proporcionando una interfaz unificada para un conjunto de subsistemas, definiendo una interfaz de nivel más alto. Esto hace que el sistema sea más fácil de usar. 

Este patrón busca reducir al mínimo la comunicación y dependencias entre subsistemas. Para ello, utilizaremos una fachada, simplificando la complejidad al cliente. El cliente debería acceder a un subsistema a través del Facade. De esta manera, se estructura un entorno de programación más sencillo, al menos desde el punto de vista del cliente (por ello se llama "fachada").

Ref: http://migranitodejava.blogspot.com.es/2011/06/facade.html

Organización del programas sin usar el patrón y usandolo.
(http://powerdream5.wordpress.com/tag/facade-pattern/ )

Los clientes se comunican con el subsistema a través de la facade, que reenvía las peticiones a los objetos del subsistema apropiados y puede realizar también algún trabajo de traducción. Los clientes que usan la facade no necesitan acceder directamente a los objetos del sistema.

Ejemplo:  (ref:  http://migranitodejava.blogspot.com.es/2011/06/facade.html )
Vamos a realizar el software para una inmobiliaria. Una inmobiliaria realiza muchos trabajos diferentes, como:
- el cobro de alquiler
- muestra de inmuebles
- administración de consorcios
- contratos de ventas
- contratos de alquiler
- etc.

Por una cuestión de seguir el paradigma de programación orientada a objetos, es probable que no se realice todo a una misma clase, sino que se dividen las responsabilidades en diferentes clases.

En el soft de la inmobiliaria tenemos diversos tipos de Personas, todas con sus atributos y métodos correspondientes.Lo mismo con los métodos principales de las diversas clases que tiene el sistema.

Ahora haremos una clase llamada Inmobiliaria que será nuestro Facade

Para ver las ventajas de usar el patrón, veamos ahora 2 tipos de clientes.
-> El primero no llamará al Facade
-> y el segundo si lo utilizará.
Veremos como el primero esta obligado a conocer muchos detalles de los subsistemas y el segundo no.
Proyecto:

Las clases:
Clase AdministracionAlquiler

Clase CuentasAPagar

Clase MuestraPropiedad

Clase VentaInmueble

Clase Inmobiliaria (esta clase hará la función clase FACADE "fachada")

Clase Persona

Clase Cliente

Clase Interesado

Clase Propietario

El programa principal:

Salida por pantalla:

Descarga del código fuente: enlace a box.com


Consecuencias.

• Oculta a los clientes de la complejidad del subsistema y lo hace fácil de usar.
• Favorece un acoplamiento débil entre el subsistema y sus clientes, consiguiendo que los cambios de las clases del sistema sean transparentes a los clientes.
• Facilita la división en capas y reduce dependencias de compilación.
• No se impide el acceso a las clases del sistema.

Temas a tener en cuenta.

• Lo más importante de todo es que este patrón se debe aplicar en las clases más representativas y no en las específicas. De no ser así, posiblemente no se tenga el nivel alto deseado. 
• Por aplicación, es ideal construir no demasiados objetos Facade. Sólo algunos representativos que contengan la mayoría de las operaciones básicas de un sistema.

Es interesante el uso de este patrón, en trabajos en grupo, donde cada persona se dedica a subsistemas concretos, y los demas, si necesitan usarlos, lo usan mediante la clase "FACADE" (Fachada). En nuestro ejemplo la clase "Inmobiliaria".
Enlaces:
http://migranitodejava.blogspot.com.es/2011/06/facade.html

http://zarza.fis.usal.es/~fgarcia/docencia/poo/03-04/Trabajos/Fachada.pdf

http://powerdream5.wordpress.com/tag/facade-pattern/