I'm not really understanding the point of a facade.
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();
}
}
If I have this code and then I have an EJB like this.
@Stateless
public class WrapSpecFacade extends AbstractFacade<WrapSpec> {
@PersistenceContext
private EntityManager em;
@Override
protected EntityManager getEntityManager() {
return em;
}
public WrapSpecFacade() {
super(WrapSpec.class);
}
}
What is the point of this? Why call this a facade? To me it's just an abstract class that groups similar functionality. Thanks.
Facade is a design pattern. A pattern, a software pattern, is a set of rules in order to organize code and provide a certain structure to it. Some goals can be reached by using a pattern.
A design pattern is used when designing the application.
The Facade pattern allows programmers to create a simple interface for objects to use other objects.
Consider working with a very complex group of classes, all implementing their own interfaces.
Well, you want to provide an interface to expose only some functionality of the many you have.
By doing so, you achieve code simplicity, flexibility, integration and loose-coupling.
Facade, in your example, is used in order to manage coupling between many actors. It is a design issue. When you have many components interacting together, the more they are tied the harder it will be to maintain them (I mean code maintenance). Facade allows you to reach loose coupling, which is a goal a programmer should always try to reach.
Consider the following:
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
...
...
}
If you had to change business logic located in a class used by call1 or call2... by not changing the interface, you would not need to change all these classes, but just the class inside the method used by one of the interface methods of the first two classes.
Facade lets you improve this mechanism.
I am sorry but I realize that it does not look so wonderful. Design patterns are heavily used in the software industry and they can be very useful when working on large projects.
You might point out that your project is not that large and that may be true, but Java EE aims to help business and enterprise-level application programming. That's why sometimes the facade pattern is used by default (some IDEs use it too).
Typically this pattern is used to either hide the implementation of the underlying classes it is presenting an interface for, or to simplify the underlying implementation of something that may be complex.
A facade may present a simple interface to the outside world, but under the hood do things like create instances of other classes, manage transactions, handle files or TCP/IP connections -- all stuff that you can be shielded from by the simplified interface.
In your particular context, this is not really a Facade. What you have in that code is basically a DAO (Data Access Object).
A DAO can be seen as a Facade for DB operations, but this is not its main purpose. It mainly intends to hide the DB internals. In your example, if you're switching the underlying storage system to XML files or to some key-value store like HBase, you can still use the methods defined in that "Facade" and no change is required in the client code.
A (traditional) Facade deals with complex designs that need to be hidden from the clients. Instead of exposing a complex API and complex flows (get this from this service, pass it to this converter, get the result and validate it with this and then send it to this other service), you just encapsulate all that in a Facade and simply expose a simple method to clients. This way, along with the fact that your API is a lot easier to use, you are also free to change the underlying (complex) implementation without breaking your clients code.