What do you think about the best way to implements JSF 2.0 managed beans utility methods such as :
public FacesContext getFacesContext() {
return FacesContext.getCurrentInstance();
}
public Flash getFlash() {
return getFacesContext().getExternalContext().getFlash();
}
public void addMessage(String clientId, String message) {
FacesMessage facesMessage = new FacesMessage(FacesMessage.SEVERITY_INFO, message,
message);
getFacesContext().addMessage(clientId, facesMessage);
}
I'm thinking either as a abstract class or a normal class with static methods.
My understanding is that object resulting from extending classes will consumes more memory but most(nearly all) of them are request scoped so eligible for garbage collection as soon as the response is rendered.
I'm interested in the best OO design and the least taxing for the server. Thanks
My understanding is that object resulting from extending classes will consumes more memory
This is not true. Only state consumes more memory. Those methods don't have/use additional state -which is exactly the reason that you can make them static
without worrying about threadsafety issues.
And yes, you see this indeed being solved in two main ways:
Put them in an abstract class
which you let all your managed beans extend.
public class Bean extends BaseBean {
public void submit() {
addInfoMessage("Submit successful");
}
}
Put them in an utility class which you can eventually import by import static
(no, don't confuse it with a singleton since a singleton has state, but an utility class hasn't).
public class Bean {
public void submit() {
Jsf.addInfoMessage("Submit successful");
}
}
Both are acceptable, the main difference is only that the abstract class way is better mockable/testable by testing frameworks, might it happen that it is a strict business requirement.
I don't think you should be too concerned about the added performance impact of a superclass with JSF 2.0. In my project we have created an abstract base class which all "Backing Beans" which act as the controller extend. The methods are similar to what you have added and include others too. Personally I would go for the abstract base class approach e.g. call it GenericBean or GenericPageCode and the IS-A relationship holds just fine. I guess one potential downside is that this abstract base class will be part of the framework and all implementations of it will be sensitive to change in it... but that should be just fine, as the methods in the base class are not likely to change often and break concrete implementations.
Of course the alternative is a singleton somewhere holding these methods or static methods on a Helper class. That's not my personal preference as you have to import the class each time and either get its instance or call the method on the Class each time. Having the methods through inheritance is preferable to me.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With