Template Methods

Daniel, algumas coisas não ficaram muito claras para mim. Por exemplo, qual a vantagem em se usar esse pattern ao inves de definir uma interface?! Não sei porque, mas, quando terminei de ler fiquei pensando na complicação que seria usar a tal da “hook operation” já que a adição de uma nova operação pode ser interessante apenas para alguma(s) da(s) classe(s) concreta(s). As outras acabariam tendo que executar o metodo tambem. Alem disso, vc disse: "não sobrecarregue o “template method”; para evitar este problema, declare o método template “final”. Há alguma maneira de se introduzir uma hook operation?

De qualquer maneira, talvez eu apenas não tenha etendido bem em que tipos de situações usar melhor o pattern. Vc poderia dar outro exemplo?!

Até.

Quando você define apenas uma interface, você está definindo apenas um contrato entre classes, mas não define nada em relação à forma como trabalha sua regra de negócio.
Porém, quando você usa um template method, você torna este vínculo entre as classes mais forte ainda, pois no método template da classe abstrata você está explicítamente determinando o roteiro a ser seguido por qualquer classe que especialize sua regra de negócio.

A “hook operation” funciona como uma “carta na manga”, para flexibilizar um pouco mais o método template. Seu uso não é obrigatório, mas pode ser útil em situações em que algumas operações do seu algoritmo podem ser facultativas.

Agora, poxa, exemplos são difíceis. Eu sou péssimo para dar exemplos. Se alguém aí quiser me socorrer, agradeço.

Ahá… apenas agora eu entendi melhor o esquema do hook: ele tambem é um metodo que as classes concretas devem implementar. Assim, se tal classe não precisa de tal operação ela define a hook “vazia”. É isso mesmo?!

Até.

Sim, é exatamente isso.

Lembrando que o método hook() normalmente não é declarado como abstrato na super classe do seu template (a classe abstrata que declara o template method) e sim implementado vazio.

Assim vc nem obriga as subclasses a declara-lo se não forem usa-lo.

Pô, agora fiquei sedento por uma comparação entre isso e Strategy.

O exemplo de acesso ao banco é interessante, mas vejo uns problemas:

1. como se lida com falhas? Se meu query() não faz nada, posso executar o process()?

2. Vou acabar tendo uma hierarquia meio besta: provavelmente eu vou ter uma classe que implementa connect() e disconnect(), da qual eu derivo as outras.

3. Me soa meio AOP de pobre.

Desculpa meter o pau logo de cara, mas eu quero é entender melhor, se é um padrão, é pq traz vantagens. Acho que faltou discutir as forças envolvidas na adoção desse pattern, e as vantagens de seguir esse caminho…

aquelão!

No caso de falha, o template method poderia fazer essa verificacao… vc teria um “contrato mais forte” de uso… algo como retornar um codigo de status, ou adicionar um exception listener…

Rafael

“Daniel Quirino Oliveira”:

Eu sou péssimo para dar exemplos. Se alguém aí quiser me socorrer, agradeço.

Eu fiz isto esta semana e nem sabia que isto era um pattern

Eu tive que transformar uma planilha gigante do excel para um sistema Java.

meu código (o esqueleto dele pq minha classe abstrata tinha um pouco mais de lógica)

public abstract class UnidadeNegocioBO {
	public abstract void getInfoAdicionais(UnidadeNegocioVO unidadeNegocio);
	public abstract void aplicarFormula(UnidadeNegocioVO unidadeNegocio);
	public abstract void update(UnidadeNegocioVO unidadeNegocio);

	public final void calcular(UnidadeNegocioVO unidadeNegocio){
		getInfoAdicionais(unidadeNegocio); // pegava informações adicionais necessárias para os cálculos
		aplicarFormula(unidadeNegocio); // aplicava as fórmulas como na planilha do excel	
		update(unidadeNegocio); // update no banco
	}
}

Assim minhas subclasses apenas implementavam os métodos que levariam a aplicar as fórmulas…