design patterns - patrones - ¿Puedes explicar el patrón de diseño del contexto?

patrones de diseño java

Question

Empecé a leer sobre el patrón de diseño Contexto . Esto es lo que entendí del texto:

• tienes un mapa que contiene todas tus variables

• se lo pasas a quien lo necesite, para que no tengas que enviar todas las variables como parámetros del método

¿Lo "conseguí"?

Answer 1

¿Lo "conseguí"?

Perdón por decir que no del todo.

El objetivo de Context Object no es pasar muchos parámetros a los métodos de forma implícita, como un medio de pasar por alto el mecanografiado fuerte y el encapsulado. El objetivo es almacenar los datos del ámbito de forma general, pero administrada, independientemente de los protocolos y la tecnología de presentación. Los datos almacenados dentro de un alcance son, por naturaleza, compartidos, pueden estructurarse y son intrínsecamente diferentes de los parámetros excepcionales que se pasan a un método.

El patrón de objeto de contexto se introdujo por primera vez en los patrones Core J2EE 2nd Ed . La parte ''Contexto'' se refiere al hecho de que el Objeto contiene datos en el Contexto de un alcance
(como application/session/request/conversation/flash ).

Su propósito es desacoplar, en la medida de lo posible, los datos de aplicación y la lógica de las clases específicas de protocolo / presentación-tecnología como HttpSession y HttpRequest .

Implementación de patrones

En Objeto de contexto, los datos destinados a application / session / request / other scope no se HttpSession directamente en ServletContext / HttpSession / HttpRequest / otra clase específica de protocolo. En cambio, los datos se almacenan en una clase de contenedor POJO, que luego se ubica en ServletRequest / HttpSession / HttpRequest / other.

El objeto de contexto puede almacenar los datos en un mapa, pero no es necesario; puede almacenar los datos en cualquier estructura / formato relevante para el programa.

Una aplicación puede usar una clase de objeto de contexto por alcance, o varias clases que dividen los datos de forma ordenada, evitando una excesiva agitación de clase y promoviendo la separación de preocupaciones.

El objeto de contexto es utilizado por las clases de presentación más avanzadas (vistas, controladores frontales, despachadores). Estos objetos de cliente de presentación llaman a contextObject.get para recuperar datos de ámbito almacenados y contextObject.put para almacenar datos de contexto de ámbito.

No se pasa a la lógica de negocios / integración. No se usa como un medio para pasar una multitud de parámetros en objetos comerciales, evitando el tipado fuerte. Los Niveles de negocios e integración están liderados por delegados comerciales, servicios de aplicaciones y / o fachadas de sesión que usan parámetros específicos de tipo fuerte.

Beneficios del patrón

• Capacidad de prueba: las pruebas unitarias solo necesitan simular un POJO simple, en lugar de una clase de servidor complejo específico del protocolo, como ServletContext o HttpRequest
• Flexibilidad y reutilización: el núcleo de la aplicación funciona independientemente de la capa de clases de ''presentación'' específica del protocolo. Esto significa que una aplicación puede cambiar o agregar protocolos o tecnología de presentación más fácilmente (por ejemplo, HTML / HTTP / Servlet y WAP / Servlet y XML / SOAP / HTTP / EJB y HTML / HTTP / JSF).

Comentarios

• Es un patrón histórico
• Se podría argumentar que los marcos de inyección de dependencia, como CDI, Guice, Spring, Seam y otros, proporcionan almacenamiento de alcance ya implementado de una manera independiente del protocolo. es decir, que todos los ámbitos ya están implementados como objetos de contexto, lo que significa que el desarrollador está menos obligado a crear objetos de contexto adicionales. Eso no niega el patrón, significa que el marco CDI ya admite el patrón.
• Si se implementa incorrectamente, uno puede terminar con el antipatrón "Pase alrededor de objetos de contexto gigantesco a lo largo de la aplicación"

Citando a KaptajnKold: Creo que lo tienes. Sin embargo, también creo que es más un anti patrón que evitar. Vea por qué here .

Sus comentarios se refieren a la versión mal implementada de Context Object. Contexto Object en sí mismo no es un antipatrón.

Answer 2

El contexto es un patrón anti, ya que se utiliza como contenedor de lo desconocido a priori.

Answer 3

Una clase que usa contexto para inializar. Considera este código

public class BuildTagHandler extends TagHandler {

      public BuildTagHandler(ServiceContext context) {  // constructor
            this.tagDAO = context.getTagDAO();
            this.buildDAO = context.getBuildDAO();
      }

Usarás el contexto para construir tu clase. En el archivo de contexto , no tendrá implementaciones, en su lugar, tiene una gran cantidad de estos objetos DAO

Puede interpretarlo como un patrón de fachada, o una interfaz enorme que cubre todas las entradas.

Answer 4

Un objeto de contexto proporciona acceso a datos y funciones compartidos.

Puede ser un sustituto elegante y flexible para:

• globals
• singletons
• largas listas de parámetros

El ACCU proporciona una descripción más detallada.

Si desea un ejemplo del mundo real del patrón de contexto en Java, consulte las API de Google Android .

Debe tener en cuenta su gráfico de dependencia cuando use el patrón de contexto. (Esta es la razón por la que KaptajnKold lo llama antipatrón).

Para limitar dependencias innecesarias, use contextos diferentes para diferentes propósitos. Mantenga sus contextos lo más simple posible y use composición o herencia para agregar complejidad cuando sea necesario.