Los patrones de diseño representan las mejores prácticas utilizadas por los desarrolladores de software orientados a objetos con experiencia. Los patrones de diseño son soluciones a los problemas generales que enfrentan los desarrolladores de software durante el desarrollo de software. Numerosos desarrolladores de software obtuvieron estas soluciones mediante prueba y error durante un período de tiempo considerable.
En 1994, cuatro autores Erich Gamma, Richard Helm, Ralph Johnson y John Vlissides publicaron un libro titulado Design Patterns - Elements of Reusable Object-Oriented Software que inició el concepto de Design Pattern en el desarrollo de software. Estos autores se conocen colectivamente como Gang of Four (GOF).
Los patrones de diseño se pueden clasificar en tres categorías: patrones de creación, estructurales y de comportamiento.
Creational Patterns- Estos patrones de diseño proporcionan una forma de crear objetos mientras se oculta la lógica de creación, en lugar de instanciar objetos directamente utilizando el nuevo opreator. Esto le da al programa más flexibilidad para decidir qué objetos deben crearse para un caso de uso dado.
Structural Patterns- Estos patrones de diseño se refieren a la composición de clases y objetos. El concepto de herencia se utiliza para componer interfaces y definir formas de componer objetos para obtener nuevas funcionalidades.
Behavioral Patterns - Estos patrones de diseño se refieren específicamente a la comunicación entre objetos.
Estos patrones de diseño se refieren específicamente al nivel de presentación. Sun Java Center identifica estos patrones.
El patrón de fábrica es uno de los patrones de diseño más utilizados en Java. Este tipo de patrón de diseño se incluye en el patrón de creación, ya que este patrón proporciona una de las mejores formas de crear un objeto.
En el patrón de fábrica, creamos un objeto sin exponer la lógica de creación al cliente y nos referimos al objeto recién creado usando una interfaz común.
Los patrones de Abstract Factory funcionan alrededor de una súper fábrica que crea otras fábricas. Esta fábrica también se denomina fábrica de fábricas. Este tipo de patrón de diseño se incluye en el patrón de creación, ya que este patrón proporciona una de las mejores formas de crear un objeto.
En el patrón Abstract Factory, una interfaz es responsable de crear una fábrica de objetos relacionados sin especificar explícitamente sus clases. Cada fábrica generada puede dar los objetos según el patrón de fábrica.
El patrón Singleton es uno de los patrones de diseño más simples de Java. Este tipo de patrón de diseño se incluye en el patrón de creación, ya que este patrón proporciona una de las mejores formas de crear un objeto.
Este patrón involucra una sola clase que es responsable de crear un objeto mientras se asegura de que solo se cree un objeto. Esta clase proporciona una forma de acceder a su único objeto al que se puede acceder directamente sin necesidad de instanciar el objeto de la clase.
Es un proceso de dos pasos. Primero, haga que el constructor sea privado para que no se pueda usar un operador nuevo para instanciar la clase. Devuelve un objeto del objeto si no es nulo; de lo contrario, crea el objeto y devuelve el mismo mediante un método.
A continuación se muestran las diferencias entre una clase estática y una clase singleton.
Una clase estática no puede ser una clase de nivel superior y no puede implementar interfaces donde una clase singleton puede hacerlo.
Todos los miembros de una clase estática son estáticos, pero para una clase Singleton no es un requisito.
Una clase estática se inicializa cuando se carga, por lo que no se puede cargar de forma diferida donde una clase singleton se puede cargar de forma diferida.
Un objeto de clase estática se almacena en la pila, mientras que el objeto de clase individual se almacena en el espacio de memoria del montón.
Si.
Lanza una excepción dentro del cuerpo del método clone ().
A continuación se muestran algunos de los patrones de diseño que se utilizan en la biblioteca JDK.
El patrón Decorator es utilizado por las clases Wrapper.
El patrón Singleton es utilizado por Runtime, clases de Calendar.
El patrón de fábrica lo usa la clase Wrapper como Integer.valueOf.
El patrón de observador es utilizado por marcos de manejo de eventos como swing, awt.
El patrón de fábrica encapsula los detalles de implementación y la implementación subyacente se puede cambiar sin ningún impacto en la API de llamadas.
El patrón de constructor construye un objeto complejo usando objetos simples y usando un enfoque paso a paso. Este constructor es independiente de otros objetos.
El patrón de prototipo se refiere a la creación de un objeto duplicado teniendo en cuenta el rendimiento. Este patrón implica la implementación de una interfaz prototipo que le dice que cree un clon del objeto actual.
Este patrón se utiliza cuando la creación de un objeto directamente es costosa. Por ejemplo, un objeto debe crearse después de una costosa operación de base de datos. Podemos almacenar en caché el objeto, devolver su clon en la próxima solicitud y actualizar la base de datos cuando sea necesario, reduciendo así las llamadas a la base de datos.
El patrón de adaptador funciona como un puente entre dos interfaces incompatibles. Este patrón involucra una sola clase que se encarga de unir funcionalidades de interfaces independientes o incompatibles.
Un ejemplo de la vida real podría ser un caso de lector de tarjetas que actúa como un adaptador entre la tarjeta de memoria y una computadora portátil. Conecta la tarjeta de memoria en el lector de tarjetas y el lector de tarjetas en la computadora portátil para que la tarjeta de memoria se pueda leer a través de la computadora portátil.
Bridge se usa cuando necesitamos desacoplar una abstracción de su implementación para que los dos puedan variar de forma independiente. Este tipo de patrón de diseño viene bajo patrón estructural ya que este patrón desacopla la clase de implementación y la clase abstracta al proporcionar una estructura de puente entre ellas.
Este patrón involucra una interfaz que actúa como un puente que hace que la funcionalidad de clases concretas sea independiente de las clases implementadoras de interfaz. Ambos tipos de clases pueden modificarse estructuralmente sin que se afecten entre sí.
El patrón de filtro o patrón de criterios es un patrón de diseño que permite a los desarrolladores filtrar un conjunto de objetos utilizando diferentes criterios y encadenarlos de forma desacoplada mediante operaciones lógicas. Este tipo de patrón de diseño viene bajo patrón estructural ya que este patrón combina múltiples criterios para obtener criterios únicos.
El patrón compuesto se usa cuando necesitamos tratar un grupo de objetos de manera similar como un solo objeto. El patrón compuesto compone objetos en términos de una estructura de árbol para representar una parte y una jerarquía completa. Este tipo de patrón de diseño viene bajo patrón estructural ya que este patrón crea una estructura de árbol de grupo de objetos.
Este patrón crea una clase que contiene un grupo de sus propios objetos. Esta clase proporciona formas de modificar su grupo de mismos objetos.
El patrón de decorador permite al usuario agregar nueva funcionalidad a un objeto existente sin alterar su estructura. Este tipo de patrón de diseño se incluye en el patrón estructural, ya que este patrón actúa como un envoltorio para la clase existente.
Este patrón crea una clase decoradora que envuelve la clase original y proporciona funcionalidad adicional manteniendo intacta la firma de los métodos de clase.
El patrón de fachada oculta las complejidades del sistema y proporciona una interfaz al cliente mediante la cual el cliente puede acceder al sistema. Este tipo de patrón de diseño viene bajo patrón estructural ya que este patrón agrega una interfaz al sistema existente para ocultar sus complejidades.
Este patrón involucra una sola clase que proporciona métodos simplificados requeridos por el cliente y delega llamadas a métodos de clases de sistema existentes.
El patrón de peso mosca se utiliza principalmente para reducir la cantidad de objetos creados y para disminuir la huella de memoria y aumentar el rendimiento. Este tipo de patrón de diseño se incluye en el patrón estructural, ya que este patrón proporciona formas de disminuir el número de objetos, mejorando así la estructura del objeto de aplicación.
El patrón Flyweight intenta reutilizar objetos similares ya existentes almacenándolos y crea un nuevo objeto cuando no se encuentra ningún objeto coincidente.
En el patrón de proxy, una clase representa la funcionalidad de otra clase. Este tipo de patrón de diseño viene bajo patrón estructural.
En el patrón de proxy, creamos un objeto que tiene un objeto original para interconectar su funcionalidad con el mundo exterior.
Como sugiere el nombre, el patrón de cadena de responsabilidad crea una cadena de objetos receptores para una solicitud. Este patrón desacopla al remitente y al receptor de una solicitud según el tipo de solicitud. Este patrón viene bajo patrones de comportamiento.
En este patrón, normalmente cada receptor contiene una referencia a otro receptor. Si un objeto no puede manejar la solicitud, pasa la misma al siguiente receptor y así sucesivamente.
El patrón de comando es un patrón de diseño basado en datos y se incluye en la categoría de patrón de comportamiento. Una solicitud se envuelve bajo un objeto como comando y se pasa al objeto invocador. El objeto invocador busca el objeto apropiado que puede manejar este comando y pasa el comando al objeto correspondiente que ejecuta el comando.
El patrón de intérprete proporciona una forma de evaluar la gramática o la expresión del lenguaje. Este tipo de patrón viene bajo un patrón de comportamiento. Este patrón implica implementar una interfaz de expresión que indica interpretar un contexto particular.
Este patrón se utiliza en el análisis de SQL, el motor de procesamiento de símbolos, etc.
El patrón de iterador es un patrón de diseño muy utilizado en el entorno de programación Java y .Net. Este patrón se utiliza para obtener una forma de acceder a los elementos de un objeto de colección de manera secuencial sin necesidad de conocer su representación subyacente. El patrón de iterador se incluye en la categoría de patrón de comportamiento.
A continuación se muestran las entidades de este tipo de patrón de diseño.
Service- Servicio real que tramitará la solicitud. La referencia de dicho servicio debe consultarse en el servidor JNDI.
Context / Initial Context - El contexto JNDI lleva la referencia al servicio utilizado para fines de búsqueda.
Service Locator - Service Locator es un único punto de contacto para obtener servicios mediante búsqueda JNDI almacenando en caché los servicios.
Cache - Caché para almacenar referencias de servicios para reutilizarlos.
Client - Cliente es el objeto que invoca los servicios a través de ServiceLocator.
El patrón de mediador se utiliza para reducir la complejidad de la comunicación entre múltiples objetos o clases. Este patrón proporciona una clase mediadora que normalmente maneja todas las comunicaciones entre diferentes clases y admite un fácil mantenimiento del código mediante un acoplamiento flexible. El patrón de mediador se incluye en la categoría de patrón de comportamiento.
El patrón de recuerdo se utiliza para restaurar el estado de un objeto a un estado anterior. El patrón de recuerdo se incluye en la categoría de patrón de comportamiento.
El patrón Memento utiliza tres clases de actores. Memento contiene el estado de un objeto a restaurar. El originador crea y almacena estados en los objetos Memento y el objeto Caretaker es responsable de restaurar el estado del objeto desde Memento.
El patrón de observador se utiliza cuando existe una relación de uno a muchos entre objetos, por ejemplo, si un objeto se modifica, sus objetos dependientes deben notificarse automáticamente. El patrón de observador se incluye en la categoría de patrón de comportamiento.
El patrón de observador utiliza tres clases de actores. Sujeto, observador y cliente. El sujeto es un objeto que tiene métodos para adjuntar y separar observadores de un objeto cliente. Hemos creado una clase abstracta Observador y una clase concreta Sujeto que está ampliando la clase Observador.
En el patrón de estado, el comportamiento de una clase cambia según su estado. Este tipo de patrón de diseño se incluye en el patrón de comportamiento. En el patrón de estado, creamos objetos que representan varios estados y un objeto de contexto cuyo comportamiento varía a medida que cambia su objeto de estado.
En el patrón de objeto nulo, un objeto nulo reemplaza la comprobación de la instancia de objeto NULO. En lugar de poner if check para un valor nulo, Null Object refleja una relación de no hacer nada. Este objeto nulo también se puede utilizar para proporcionar un comportamiento predeterminado en caso de que los datos no estén disponibles.
En el patrón Objeto nulo, creamos una clase abstracta que especifica varias operaciones a realizar, clases concretas que extienden esta clase y una clase de objeto nulo que proporciona una implementación sin hacer nada de esta clase y se usará sin problemas cuando necesitemos verificar el valor nulo.
En el patrón de estrategia, el comportamiento de una clase o su algoritmo se puede cambiar en tiempo de ejecución. Este tipo de patrón de diseño se incluye en el patrón de comportamiento.
En el patrón de estrategia, creamos objetos que representan varias estrategias y un objeto de contexto cuyo comportamiento varía según su objeto de estrategia. El objeto de estrategia cambia el algoritmo de ejecución del objeto de contexto.
En el patrón de plantilla, una clase abstracta expone formas / plantillas definidas para ejecutar sus métodos. Sus subclases pueden anular la implementación del método según sea necesario, pero la invocación debe realizarse de la misma manera que la definida por una clase abstracta. Este patrón se incluye en la categoría de patrón de comportamiento.
En el patrón de visitante, usamos una clase de visitante que cambia el algoritmo de ejecución de una clase de elemento. De esta manera, el algoritmo de ejecución del elemento puede variar a medida que varía el visitante. Este patrón se incluye en la categoría de patrón de comportamiento. Según el patrón, el objeto del elemento tiene que aceptar el objeto del visitante para que el objeto del visitante maneje la operación en el objeto del elemento.
MVC Pattern son las siglas de Model-View-Controller Pattern. Este patrón se utiliza para separar las preocupaciones de la aplicación.
Model- El modelo representa un objeto o JAVA POJO que lleva datos. También puede tener lógica para actualizar el controlador si sus datos cambian.
View - Vista representa la visualización de los datos que contiene el modelo.
Controller- El controlador actúa tanto en el modelo como en la vista. Controla el flujo de datos hacia el objeto modelo y actualiza la vista cada vez que cambian los datos. Mantiene la vista y el modelo separados.
El patrón de delegado comercial se utiliza para desacoplar el nivel de presentación y el nivel comercial. Básicamente se utiliza para reducir la funcionalidad de comunicación o búsqueda remota al código de nivel empresarial en el código de nivel de presentación. En el nivel empresarial tenemos las siguientes entidades.
Client - El código del nivel de presentación puede ser JSP, servlet o código java UI.
Business Delegate - Una clase de punto de entrada único para que las entidades cliente proporcionen acceso a los métodos de servicios comerciales.
LookUp Service - El objeto de servicio de búsqueda es responsable de obtener la implementación comercial relativa y proporcionar acceso al objeto comercial al objeto delegado comercial.
Business Service- Interfaz de servicios comerciales. Las clases concretas implementan este servicio empresarial para proporcionar una lógica de implementación empresarial real.
El patrón de entidad compuesta se utiliza en el mecanismo de persistencia de EJB. Una entidad compuesta es un bean de entidad EJB que representa un gráfico de objetos. Cuando se actualiza una entidad compuesta, los beans de objetos dependientes internamente se actualizan automáticamente al ser administrados por el bean de entidad EJB. A continuación se muestran los participantes en Composite Entity Bean.
Composite Entity- Es un bean de entidad primario. Puede ser de grano grueso o puede contener un objeto de grano grueso que se utilizará con fines de persistencia.
Coarse-Grained Object- Este objeto contiene objetos dependientes. Tiene su propio ciclo de vida y también gestiona el ciclo de vida de los objetos dependientes.
Dependent Object - El objeto dependiente es un objeto que depende de un objeto de grano grueso para su ciclo de vida de persistencia.
Strategies - Estrategias representa cómo implementar una entidad compuesta.
El patrón de objeto de acceso a datos o patrón DAO se utiliza para separar las operaciones o la API de acceso a datos de bajo nivel de los servicios comerciales de alto nivel. A continuación se muestran los participantes en el patrón de objetos de acceso a datos.
Data Access Object Interface - Esta interfaz define las operaciones estándar que se realizarán en un objeto (s) modelo.
Data Access Object concrete class- Esta clase implementa la interfaz anterior. Esta clase es responsable de obtener datos de una fuente de datos que puede ser una base de datos / xml o cualquier otro mecanismo de almacenamiento.
Model Object or Value Object - Este objeto es un POJO simple que contiene métodos get / set para almacenar datos recuperados usando la clase DAO.
El patrón de diseño del controlador frontal se utiliza para proporcionar un mecanismo de manejo de solicitudes centralizado de modo que todas las solicitudes sean manejadas por un solo controlador. Este controlador puede realizar la autenticación / autorización / registro o seguimiento de la solicitud y luego pasar las solicitudes a los controladores correspondientes. A continuación se muestran las entidades de este tipo de patrón de diseño.
Front Controller - Un solo controlador para todo tipo de solicitudes que llegan a la aplicación (ya sea en la web o en el escritorio).
Dispatcher - El controlador frontal puede usar un objeto despachador que puede enviar la solicitud al manejador específico correspondiente.
View - Las vistas son el objeto para el que se realizan las solicitudes.
El patrón de diseño de filtro de interceptación se utiliza cuando queremos hacer un preprocesamiento / posprocesamiento con la solicitud o respuesta de la aplicación. Los filtros se definen y aplican en la solicitud antes de pasar la solicitud a la aplicación de destino real. Los filtros pueden realizar la autenticación / autorización / registro o seguimiento de la solicitud y luego pasar las solicitudes a los controladores correspondientes.
A continuación se muestran las entidades de este tipo de patrón de diseño.
Filter - Filtro que realizará determinada tarea antes o después de la ejecución de la solicitud por parte del controlador de solicitudes.
Filter Chain - Filter Chain lleva varios filtros y ayuda a ejecutarlos en un orden definido en el objetivo.
Target - El objeto de destino es el controlador de solicitudes.
Filter Manager - Filter Manager gestiona los filtros y la cadena de filtros.
Client - El cliente es el objeto que envía la solicitud al objeto de destino.
El patrón de diseño del localizador de servicios se usa cuando queremos ubicar varios servicios usando la búsqueda JNDI. Teniendo en cuenta el alto costo de buscar JNDI para un servicio, el patrón del localizador de servicios hace uso de la técnica de almacenamiento en caché. Por primera vez, se requiere un servicio, Service Locator busca en JNDI y almacena en caché el objeto de servicio. La búsqueda adicional o el mismo servicio a través de Service Locator se realiza en su caché, lo que mejora el rendimiento de la aplicación en gran medida.
El patrón Transferir objeto se utiliza cuando queremos pasar datos con múltiples atributos en una sola toma de cliente a servidor. El objeto de transferencia también se conoce como objeto de valor. Transfer Object es una clase POJO simple que tiene métodos getter / setter y es serializable para que pueda transferirse a través de la red. No tiene ningún comportamiento. La clase empresarial del lado del servidor normalmente obtiene datos de la base de datos y llena el POJO y lo envía al cliente o lo pasa por valor. Para el cliente, el objeto de transferencia es de solo lectura. El cliente puede crear su propio objeto de transferencia y pasarlo al servidor para actualizar los valores en la base de datos de una sola vez. A continuación se muestran las entidades de este tipo de patrón de diseño.
Business Object - Business Service llena el Transfer Object con datos.
Transfer Object - POJO simple que tiene métodos para establecer / obtener atributos únicamente.
Client - El cliente solicita o envía el objeto de transferencia al objeto comercial.