Блог

Что вы думаете о наилучшем способе реализации служебных методов управляемых компонентов JSF 2.0, таких как :

 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);        
}
  

Я думаю либо как абстрактный класс, либо как обычный класс со статическими методами.

Насколько я понимаю, объект, возникающий в результате расширения классов, будет потреблять больше памяти, но большинство (почти все) из них ограничены областью запроса, поэтому могут быть использованы для сборки мусора, как только будет получен ответ.

Я заинтересован в лучшем дизайне OO и наименьших затратах на сервер. Спасибо

Насколько я понимаю, объект, возникающий в результате расширения классов, будет потреблять больше памяти

Это неправда. Больше памяти потребляет только состояние. Эти методы не имеют / не используют дополнительное состояние — именно по этой причине вы можете создавать их static , не беспокоясь о проблемах безопасности потоков.

И да, вы видите, что это действительно решается двумя основными способами:

1. Поместите их в abstract class , который вы разрешаете расширять всем вашим управляемым компонентам.

    public class Bean extends BaseBean {
       public void submit() {
           addInfoMessage("Submit successful");
       }
   }
     

2. Поместите их в служебный класс, который вы в конечном итоге сможете импортировать с помощью import static (нет, не путайте его с синглтоном, поскольку синглтон имеет состояние, а служебный класс — нет).

    public class Bean {
       public void submit() {
           Jsf.addInfoMessage("Submit successful");
       }
   }
     

Оба приемлемы, основное отличие заключается только в том, что способ абстрактного класса лучше поддается макетированию / тестированию с помощью тестовых фреймворков, может случиться так, что это строгое бизнес-требование.

Я не думаю, что вам следует слишком беспокоиться о дополнительном влиянии суперкласса на производительность с JSF 2.0. В моем проекте мы создали абстрактный базовый класс, который расширяют все «вспомогательные компоненты», которые действуют как контроллер. Методы аналогичны тем, что вы добавили, и включают в себя и другие. Лично я бы выбрал подход абстрактного базового класса, например, назовите его GenericBean или GenericPageCode, и отношение IS-A выполняется просто отлично. Я предполагаю, что одним из потенциальных недостатков является то, что этот абстрактный базовый класс будет частью фреймворка, и все его реализации будут чувствительны к изменениям в нем… но это должно быть просто замечательно, поскольку методы в базовом классе вряд ли будут часто меняться и нарушать конкретные реализации.

Конечно, альтернативой является синглтон, который где-то содержит эти методы или статические методы в вспомогательном классе. Это не мое личное предпочтение, поскольку вам приходится каждый раз импортировать класс и либо получать его экземпляр, либо каждый раз вызывать метод в классе. Для меня предпочтительнее использовать методы через наследование.