Rodrigo Allemand

Finalmente, codificando…

Seguindo  o combinado, nessa quarta e última parte vamos começar a codificação do nosso exemplo de Fluent Interface usando Notifications.

Inicialmente, a lista, onde ficarão as mensagens criadas.

public class NotificationList
	extends ArrayList<NotificationMessage> {

private static ThreadLocal<NotificationList> threadList
	= new ThreadLocal<NotificationList>();

private NotificationList() {
}

public static NotificationList getList(){
	NotificationList list = threadList.get();
	if(list == null){
		list = new NotificationList();
		threadList.set(list);
	}
	return list;
}

public static void clearMessages(){
	NotificationList list = getList();
	list.clear();
}

}

Com isso, teremos uma lista que controlará as mensagens e um Proxy que manipulará o acesso a essa lista.

Agora vamos partir para a classe de Mensagem.

public class NotificationMessage implements
	EventFluentInterface,
	FormValidationFluentInterface,
	FormValidationDetailFluentInterface {

	private String message;
	private final boolean success;

	NotificationMessage(boolean success) {
		this.success = success;
	}

	public String getMessage() {
		return message;
	}

	public boolean isError() {
		return !success;
	}
}

Algumas particularidades dessa classe:

• Ela tem um construtor protegido por pacote. Optei por isso para que o controle de criação de mensagens fique somente com a Classe Notificate (abaixo), forçando um builder que oriente a Fluent Interface.
• Os métodos das interfaces serão colocados conforme elas aparecerem.

O Builder, comentado acima, ficará a cargo da classe Notificate.

public class Notificate {

	private Notificate() {
	}

	private static NotificationMessage create(boolean flag){
		NotificationMessage message =
			new NotificationMessage(flag);
		NotificationList.getList().add(message);
		return message;
	}

	public static EventFluentInterface success(){
		return create(true);
	}

	public static EventFluentInterface failure(){
		return create(false);
	}
}

Apenas um comentário sobre o Builder: Construtor privado, ordenando a criação pelos métodos publicos estáticos.

As interfaces.

public interface EventFluentInterface {
	void onEvent(String event);
	FormValidationFluentInterface onFormValidation();
}

public interface FormValidationFluentInterface {
	FormValidationDetailFluentInterface onField(String field);
}

public interface FormValidationDetailFluentInterface {
	void isRequired();
}

Para completar, a implementação dos métodos das interfaces na classe NotificationMessage.

//Métodos de EventFluentInterface
public void onEvent(String event) {
	this.message = event;
}

public FormValidationFluentInterface onFormValidation() {
	return this;
}

//Métodos de FormValidationFluentInterface
public FormValidationDetailFluentInterface onField(String field) {
	this.message = "Campo " + field + " inválido.";
	return this;
}

//Métodos de FormValidationDetailFluentInterface
public void isRequired() {
	this.message += "O campo é requerido.";
}

Lembre-se que, a chamada de NotificationList.clearMEssges() tem que ser feita a cada request. Ai, essa implementação fica a cargo da sua arquitetura, por exemplo: Se vc usa Struts, chame isso no RequestDispatcher, se Struts2, faça um Iterceptor, se Servlet puro, faça um Filtro, etc.

Bem, é isso!
O que acharam? Espero os comentários!!!

Comente e Recomende!

Design da solução

Menti pra vcs quando falei que estava tarde…rs
Estava apenas pegando o carro e indo pra casa…

Continuando o post anterior, agora chegou a hora de colocar a mão na massa. Nem tanto ainda, primeiro precisamos desenhar a solução.

Inicialmente gostaria de falar que o diagrama de classes abaixo foi gerado pelo NetBeans 6.1 (blarg!) e “photoshopado” para ficar com uma aparência menos feia.  Alem disso, os nomes das classes/interfaces foram reduzidos para que o diagrama não ficasse muito grande.
Outro ponto a se ressaltar é que o NetBeans é meio atrasado no que diz respeito a UML. Mas, como quem não tem cão, caça com gato, ai está.

Abaixo está o diagrama de classe da Fluent Notification.
Para quem for baixar o pacote no proximo post, os nomes originais são:

• List > NotificationList
• Message > NotificationMessage
• Notificate > Notificate
• EventFI > EventFluentInterface
• FormValidationFI > FormValidationFluentInterface
• ValidationDetailFI > FormValidationDetailFluentInterface

Outra coisa a ser comentada. Não achei (inexperiência minha ou não tem mesmo) alguma coisa pra identificar que List na verdade extende de ArrayList usando-se de Generics para arquivar somente objetos do tipo Message.

Vamos ao Diagrama de Classe e deixar de Blá-Blá-Blá!

Já dá pra entender?!?
Bem, não vou comentar nada e esperar os comentários de vocês…
Amanhã tem o código realmente pronto…

Até!

Comente e Recomende!

Estudo de Caso para implementação

Antes de iniciarmos a codificação, gostaria de falar um pouco sobre o que me motivou a escrever essa série de posts sobre Fluent Interface. Em um projeto orientado a domínio, a comunicação entre este domínio e a camada de apresentação deve ser feita por um padrão catalogado por Martin Fowler chamado Notification.

Ele, basicamente diz o seguinte:

An object that collects together information about errors and other information in the domain layer and communicates it to the presentation.

Com isso, uma hora em seu dominio você terá que comunicar (o erro E/ou o sucesso) para a camada de apresentação. Em todos os projetos que eu já passei que utilizam DDD, essa comunicação era feita precariamente, onde uma classe era responsável por reter (uma ou) uma lista de mensagens a serem enviadas via Exception para a apresentação. Esta é uma implementação aceitavel, mas eu nunca achei que ela era boa e bonita.

Quando eu vim trabalhar no INCa, não existia nada sobre DDD, muito menos Notification. Com isso, surgiu a necessidade de criarmos essa estrutura de mensagens. Foi ai que eu juntei o útil (Notification) ao agradavel (Fluent Interface) e criei a FluentNotification.

O desenho inicial é basicamente este:

Explicando melhor.
Se estivessemos fingindo uma conversa do domínio com a camada de arpesentação, seria algo assim.

Notifique à camada de apresentação que houve sucesso no evento Cadastrar Pessoa.

Ou…

Notifique à camada de apresentação que houve uma falha na validação, onde o campo CPF é requerido.

Não seria legal se escrevessemos assim? Pois bem!

Vamos pensar mais um pouco.
O que eu vou precisar para que isso aconteça?

• Uma mensagem estilizada
• Uma lista dessas mensagens estilizadas
• Um proxy para manipular essas mensagens

Um outro ponto: Essa mensagem estilizada deve ter vários tipos de interface , visando expor “fluentemente” só aquilo que realmente queremos…
Repararam que na figura, existe um caminho verde? Então… eu só posso ir para “É Requerido” se eu vier de “De Validação no Campo” e com o campo preenchido.
O “Fulano” ali é onde entrará a especialização da mensagem.

Então, para um código bem feito, seguindo os padrões citados, isso deveria ser da seguinte maneira:

Notificate.aFailure().onFormValidation().onField(“CPF”).isRequired();
Notificate.aSuccess().onEvent(“Cadastrar Pessoa”);

Ficou legal, né? Claro que isso é apenas um exemplo.
Seria prudente colocar um serviço de I18N ai para internacionalizar as mensagens…
Agora vamos partir para a codificação…
Mas hoje não, né… já está tarde… rs
No próximo post, a codificação!!!!

Ah, e não esqueçam de comentar, hein!!!

Até!