Título: [Guía] Patrones de diseño - Parte 1 Publicado por: Usuario Invitado en 30 Enero 2015, 23:30 pm PATRONES DE DISEÑO: PARTE 1 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. Un patrón de diseño resulta ser una solución a un problema de diseño. Para que una solución sea considerada un patrón debe poseer ciertas características. Una de ellas es que debe haber comprobado su efectividad resolviendo problemas similares en ocasiones anteriores. Otra es que debe ser reutilizable, lo que significa que es aplicable a diferentes problemas de diseño en distintas circunstancias. Los patrones de diseño pretenden:
Asimismo, no pretenden:
No es obligatorio utilizar los patrones, solo es aconsejable en el caso de tener el mismo problema o similar que soluciona el patrón, siempre teniendo en cuenta que en un caso particular puede no ser aplicable. "Abusar o forzar el uso de los patrones puede ser un error". PATRÓN ADAPTER El patrón adapter nos permite ampliar la funcionalidad de una clase o interfaz adaptando objetos que no coinciden con una determinada jerarquía de clases. Convierte la interfaz de una clase en otra interfaz que el cliente espera. Adapter permite a las clases trabajar juntas, lo que de otra manera no podría hacerlo debido a sus interfaces incompatibles. Cuándo usarlo:
Solución: Utilizar el patrón Adapter para extender la funcionalidad de la interfaz adaptando el auto eléctrico. Creamos una interfaz llamada Car que representará de forma genérica a un Auto: Car.java Código
NOTA: el método start() lo predefinimos porque será el mismo para todos las implementaciones. Ahora sus implementaciones: GasolineCar y GasCar. Representan un auto a gasolina y otro a gas. GasolineCar.java Código
GasCar.java Código
Ambos autos, GasolineCar y GasCar necesitan combustible para funcionar. Por eso, el método fillTank llena el combustible de ellos, dependiendo si es gasolina o gas. Ahora queremos añadir un auto eléctrico a nuestra jerarquía de clases. ElectricCar.java Código
Nos damos con la sorpresa que éste auto no coincide con nuestra jerarquía. La interfaz Car dice que todos los autos que la implementen deben tener el método fillTank. Pero, ¿Como un auto eléctrico puede llenar el tanque? ¿Cómo hacemos para adaptar éste auto a nuestra jerarquía? Un error es común es modificar la interfaz o clase abstracta. Ésto viola el principio OCP, el cual nos dice: Citar Las entidades de software deben ser abiertas para ser extendidas y cerradas para no ser modificadas. Aquí toma importancia en patrón Adapter. Éste patrón nos permite ampliar la funcionalidad de una interfaz si tener que cambiar código en ella. Veamos como funciona. Código
Como vemos hemos podido adaptar nuestro auto eléctrico a nuestra interfaz Car. ¡Ahora, podemos crear tanto autos a gasolina, gas o eléctricos aplicando polimorfismo! Veamos que salida nos arroja: AdapterTest.java Código
Salida: Código: Creando un auto a gasolina... Y así podemos extender la funcionalidad de nuestra aplicación de forma sencilla y eficiente. PATRÓN FACADE Descripción: El patrón fachada viene motivado por la necesidad de estructurar un entorno de programación y reducir su complejidad con la división en subsistemas, minimizando las comunicaciones y dependencias entre éstos. Cuándo usarlo:
Solución: Aplicar el patrón Facade para encapsular todos los objetos que hacen las 3 operaciones. Bank.java Código
Deposit.java Código
Withdrawal.java Código
Ahora, creamos nuestra clase principal: FacadeTest.java Código
Como vemos creamos 3 objetos los cuales se encargan de efectuar las acciones. Pero, ¿es necesario crear éstos tres objetos en éste ambito? ¿Los vamos a necesitar siempre? Una mejor idea sería encapsular éstos objetos dentro de uno solo que se encargue de realizar todas las operaciones. Éste es el propósito del patrón Facade, actuar como intermediario entre la interfaz y las funcionalidades de un sistema. Veamos como se representa: OperationsFacade.java Código
Como podemos observar, ésta clase encapsula el comportamiento de las clases Bank, Deposit y Withdrawal. Ya no tenemos que declarar los objetos porque éstos se crean en los métodos de OperationsFacade y se destruyen al finalizar el mismo. ¡Además ahorramos memoria! Ahora, veamos como queda la clase principal: FacadeTest.java Código
Como podemos ver, solo necesitamos de un objeto OperationsFacade para realizar todas las operaciones. Así aplicamos también el principio KISS (Keep it simple stupid!). Salida: Código: Creando cuenta N° 9343435093 PATRÓN ABSTRACT FACTORY Descripción: El patrón Abstract Factory nos permite crear, mediante una interfaz, conjuntos o familias de objetos (denominados productos) que dependen mutuamuente y todo esto sin especificar cual es el objeto concreto. Cuándo usarlo:
Solución: Utilizar el patrón Abstract Factory para crear los objetos solicitados. Primero, creamos una clase abstracta llamada Animal que representará de forma genérica a un Animal: Animal.java Código
Y tres animales que extienden de Animal: Dog.java Código
Shark.java Código
Lion.java Código
Bien, ya tenemos nuestros 3 tipos de animales que heredan de Animal: Dog, Shark y Lion. Como la tarea es construir objetos sin especificar de qué tipo son, creamos una fábrica abstracta que especifica la creación de un Animal genérico sin especificar de qué tipo: AbstractAnimalFactory.java Código
Ahora, el siguiente paso es hacer las implementaciones de ésta fábrica abstracta, es decir las fábricas concretas que crearán los objetos concretos: DogFactory.java Código
SharkFactory.java Código
LionFactory.java Código
Analicemos un poco el código. Cada una de las implementaciones de AbstractAnimalFactory especifican la implementación que tendrá para crear un tipo de animal. Cada factoría concreta, tiene las 3 propiedades que necesita cada objeto para poder crearse. Así mismo, dichos datos se pasan como parámetros a su constructor para establecer los valores en las propiedades que se utilizarán para crear una instancia del objeto. Establece las propiedades: Código Y usa esas mismas propiedades para crear el objeto: Código
Finlamente, se sobre-escribe el método de la factoría abstracta createAnimal() para retornar un nuevo objeto de acuerdo al tipo de factoría. Así, la factoría de Perros, creará objetos tipo Perro, la factoría de Tiburones creará objetos tipo Tiburón y la factoría de Leones, crearán objetos tipo León. Por último, especificamos una Fábrica global que utilizará las 3 fábricas para crear los objetos (Aquí se aplica también el patrón Facade): AnimalFactory.java Código
Ésta clase recibe un objeto que implemente la interfaz AbstractAnimalFactory, por lo tanto podrá recibir objetos tipo: DogFactory, SharkFactory y LionFactory. Luego simplemente usa la factoría especificada para crear un animal mediante polimorfismo. Ahora construyamos nuestra clase principal para probar el funcionamiento del patrón: FactoryTest.java Código
Utilizamos el método estático create() de AnimalFactory que recibe una implementación de la interfaz AbstractAnimalFactory, en éste caso un objeto DogFactory al que se le asignan los valores “Perro”, “Caninos” y “Doméstico” y finalmente AnimalFactory llama al método createAnimal() de DogFactory para crear un animal tipo Dog y devolverlo hacia AnimalFactory que lo devuelve y lo guarda en el objeto 'dog'. El mismo procedimiento es para todas las factorías. Salida: Código: Tipo de animal: Perro Y de ésta manera sencilla, podemos usar tantas fábricas como queramos para poder crear objetos si generar dependencias ;) PATRÓN SINGLETON Cuándo usarlo:
Solución: Utilizar el patrón Singleton para encapsular la configuración de la aplicación. Para utilizar éste patrón se deben seguir dos reglas:
Teniendo en cuenta éstas reglas, creamos una clase que representa a la configuración de la aplicación: Configuration.java Código
Y simplemente, cuando la necesitemos, obtenemos su única instancia: SingletonTest.java Código
Salida: Código: show_hidde_files: true NOTA IMPORTANTE: Generalmente, cuando se usa éste patrón, se garantiza que solamente existirá una instancia de dicha clase. Pero, si se trata de una aplicación web y se va a integrar una aplicación web con otra, es probable que ya no exista una sola instancia. Ésto se debe a los ClassLoaders. Cada contenedor de cada aplicación web (WAR) tiene su propio ClassLoader, por lo que en el supuesto caso de una integración de WARs, las instancias serán dos y no una como se había previsto. Título: Re: [Guía] Patrones de diseño - Parte 1 Publicado por: Usuario Invitado en 31 Enero 2015, 00:00 am He creado un repositorio con ésta primera parte en Github para que lo descarguen si les interesa: Java design patterns (https://github.com/GusGarsaky/JavaDesignPatterns)
Título: Re: [Guía] Patrones de diseño - Parte 1 Publicado por: ~ Yoya ~ en 31 Enero 2015, 18:37 pm Buen aporte.
Título: Re: [Guía] Patrones de diseño - Parte 1 Publicado por: Usuario Invitado en 1 Febrero 2015, 00:15 am Gracias colega. Pensándolo mejor, el patrón Singleton es mejor aplicarlo como recomienda Joshua Bloch; como un Enum.
Código
Para gustos colores ;) Salu2. Título: Re: [Guía] Patrones de diseño - Parte 1 Publicado por: kondrag_X1 en 3 Febrero 2015, 16:51 pm Si señor ;-) mas de una vez he tenido un problema y he pensado un patron seguro que me solucionaría la vida, ahora ya sé donde acudir.
un gran trabajo. Título: Re: [Guía] Patrones de diseño - Parte 1 Publicado por: Usuario Invitado en 3 Febrero 2015, 17:03 pm Gracias por comentar. Pero esto aún no acaba, se viene la segunda parte y otras guías como JPA y WebServices ^^
Stay tuned! Título: Re: [Guía] Patrones de diseño - Parte 1 Publicado por: marlboreano en 7 Marzo 2015, 18:33 pm Muy buen aporte ;-), a leer y aplicar no más.
Título: Re: [Guía] Patrones de diseño - Parte 1 Publicado por: peib0l en 8 Marzo 2015, 00:32 am Olé Un aporte genial a la vez que necesario :D , espero leer mas cosillas asi.
Título: Re: [Guía] Patrones de diseño - Parte 1 Publicado por: Dreamaker en 3 Abril 2015, 08:25 am Genial, gracias!!! Espero la parte 2!!! ;)
Título: Re: [Guía] Patrones de diseño - Parte 1 Publicado por: Usuario Invitado en 3 Abril 2015, 14:46 pm Sí, cuando tenga un tiempito, hago las partes pendientes. También la seguna parte de JPA, donde queda ver relaciones.
Un saludo y gracias por pasar. Título: Re: [Guía] Patrones de diseño - Parte 1 Publicado por: Trane! en 21 Septiembre 2015, 23:13 pm Si en el singleton haces lazy initialization, lo mejor es hacerlo tambien "thread safe" para asegurarte de inicializarlo solo una vez. (Perdon por revivir el tema pero lo vi en destacados)
Código
Título: Re: [Guía] Patrones de diseño - Parte 1 Publicado por: jangeld en 12 Octubre 2015, 02:14 am buen tema ;-)... Habrá segunda parte?
Título: Re: [Guía] Patrones de diseño - Parte 1 Publicado por: rub'n en 8 Abril 2016, 04:47 am y patron tipo MVP MODEL VIEW PRESENTER? saludos buen post.
|