java - patrones - patrón observer

¿Cuál es el punto de una fachada en Java EE?

Question

Realmente no estoy entendiendo el punto de una fachada.

public abstract class AbstractFacade<T> {
private Class<T> entityClass;
public AbstractFacade(Class<T> entityClass) {
this.entityClass = entityClass;
}
protected abstract EntityManager getEntityManager();
public void create(T entity) {
getEntityManager().persist(entity);
}
public void edit(T entity) {
getEntityManager().merge(entity);
}
public void remove(T entity) {
getEntityManager().remove(getEntityManager().merge(entity));
}
public T find(Object id) {
return getEntityManager().find(entityClass, id);
}
public List<T> findAll() {
CriteriaQuery cq = getEntityManager().getCriteriaBuilder().createQuery();
cq.select(cq.from(entityClass));
return getEntityManager().createQuery(cq).getResultList();
}
public List<T> findRange(int[] range) {
CriteriaQuery cq = getEntityManager().getCriteriaBuilder().createQuery();
cq.select(cq.from(entityClass));
Query q = getEntityManager().createQuery(cq);
q.setMaxResults(range[1] - range[0]);
q.setFirstResult(range[0]);
return q.getResultList();
}
public int count() {
CriteriaQuery cq = getEntityManager().getCriteriaBuilder().createQuery();
Root<T> rt = cq.from(entityClass);
cq.select(getEntityManager().getCriteriaBuilder().count(rt));
Query q = getEntityManager().createQuery(cq);
return ((Long) q.getSingleResult()).intValue();
}
}

Si tengo este código y luego tengo un EJB como este.

@Stateless
public class WrapSpecFacade extends AbstractFacade<WrapSpec> {
@PersistenceContext
private EntityManager em;
@Override
protected EntityManager getEntityManager() {
return em;
}
public WrapSpecFacade() {
super(WrapSpec.class);
}
}

¿Cual es el punto de esto? ¿Por qué llamar esto una fachada? Para mí, es solo una clase abstracta que agrupa una funcionalidad similar. Gracias.

Answer 1

En su contexto particular, esto no es realmente una fachada. Lo que tienes en ese código es básicamente un DAO (Objeto de acceso a datos).

Un DAO se puede ver como una fachada para operaciones DB, pero este no es su objetivo principal. Principalmente tiene la intención de ocultar los internos de DB. En su ejemplo, si está cambiando el sistema de almacenamiento subyacente a archivos XML o a algún almacén de clave-valor como HBase, puede seguir utilizando los métodos definidos en esa "Fachada" y no se requiere ningún cambio en el código del cliente.

Una fachada (tradicional) trata con diseños complejos que deben ocultarse a los clientes. En lugar de exponer una API compleja y flujos complejos (obtener esto de este servicio, pasarlo a este convertidor, obtener el resultado y validarlo con esto y luego enviarlo a este otro servicio), simplemente encapsular todo eso en una Fachada y simplemente exponer un método simple a los clientes. De esta manera, junto con el hecho de que su API es mucho más fácil de usar, también puede cambiar la implementación subyacente (compleja) sin romper el código de sus clientes.

Answer 2

Normalmente, este patrón se utiliza para ocultar la implementación de las clases subyacentes a las que presenta una interfaz, o para simplificar la implementación subyacente de algo que puede ser complejo.

Una fachada puede presentar una interfaz simple para el mundo exterior, pero bajo el capó hacer cosas como crear instancias de otras clases, gestionar transacciones, manejar archivos o conexiones TCP / IP: todo lo que puede protegerse mediante la interfaz simplificada.

Answer 3

Fachada es un patrón de diseño. Un patrón, un patrón de software, es un conjunto de reglas para organizar el código y proporcionarle una cierta estructura. Algunos objetivos se pueden alcanzar mediante el uso de un patrón. Un patrón de diseño se usa al diseñar la aplicación.

El patrón Fachada permite a los programadores crear una interfaz simple para que los objetos usen otros objetos. Considere trabajar con un grupo de clases muy complejo, todos implementando sus propias interfaces. Bueno, desea proporcionar una interfaz para exponer solo algunas funcionalidades de las muchas que tiene. Al hacerlo, logras simplicidad de código, flexibilidad, integración y acoplamiento suelto.

Fachada, en su ejemplo, se utiliza para gestionar el acoplamiento entre muchos actores. Es un problema de diseño. Cuando tiene muchos componentes que interactúan entre sí, cuanto más estén atados, más difícil será mantenerlos (me refiero al mantenimiento del código). Fachada le permite alcanzar un acoplamiento flojo, que es un objetivo que un programador siempre debe tratar de alcanzar.

Considera lo siguiente:

public class MyClass1 implements Interface1 {
public void call1() {}
public call call2() {}
}
public class MyClass2 implements Interface2 {
public void call3() {}
public void call4() {}
}
public class MyClass {
private MyClass1 a;
private MyClass2 b;
//calling methods call1 call2 call3 and call4 in other methods of this class
...
...
}

Si tuviera que cambiar la lógica de negocio ubicada en una clase utilizada por call1 o call2 ... al no cambiar la interfaz, no necesitaría cambiar todas estas clases, sino solo la clase dentro del método utilizado por uno de los métodos de interfaz de las primeras dos clases

Facade te permite mejorar este mecanismo.

Lo siento pero me doy cuenta de que no se ve tan maravilloso. Los patrones de diseño son muy utilizados en la industria del software y pueden ser muy útiles cuando se trabaja en proyectos grandes. Puede señalar que su proyecto no es tan grande y que puede ser cierto, pero Java EE tiene como objetivo ayudar a la programación de aplicaciones empresariales y empresariales. Es por eso que a veces el patrón de fachada se usa por defecto (algunos IDE también lo usan).