Interceptors

vc diz isso?

http://docs.oracle.com/javaee/6/tutorial/doc/gkeci.html

pelo que eu entendi, esse exemplo parece ser o equivalente ao around do Moose ( Perl ).
isso é parte de programação orientada a aspectos, e isso traz coisas bem interessantes.

por exemplo, as vezes vc tem regras de negocio complexas que dariam classes gigantes e que vc pode espalhar por diversos objetos diferentes ( validação, log, metricas, coerção, tratamento de erros, etc ). ainda assim o seu codigo precisa ser inserido em algo que vai fazer essa coisa toda.

em frameworks web vc tem padrãoes como filters, hooks e outras coisas pq o framework em si esconde como é feito ( ex: vc nao precisa verificar se o usuario esta logado na servlet pq provavelmente um filter ja fez isso, vc sabe a logica do filter mas nao precisa saber como ele é aplicado - ou pelo menos nao em detalhes ). porem ainda assim pode ser que vc queria fazer algo a mais do que o framework suporta.

@Interceptors(HelloInterceptor.class)
public void setName(String name) {
    this.name = name;
}
/* The HelloInterceptor class defines an @AroundInvoke interceptor method, modifyGreeting, that converts the string passed to HelloBean.setName to lowercase. */

@AroundInvoke
public Object modifyGreeting(InvocationContext ctx) throws Exception {
    Object[] parameters = ctx.getParameters();
    String param = (String) parameters[0];
    param = param.toLowerCase();
    parameters[0] = param;
    ctx.setParameters(parameters);
    try {
        return ctx.proceed();
    } catch (Exception e) {
        logger.warning("Error calling ctx.proceed in modifyGreeting()");
        return null;
    }
}

nesse caso a especificaçào diz que, em um dado momento, alguem vai carregar a sua classe e vai detectar os interceptadores. assim vc tem suporte para rodar um codigo “ao redor” do metodo original com uma sintaxe mais simples.

eu jamais usei isso em java, mas uso e muito em Moose/Moo.

eu tento evitar a especialização por herança fazendo composição de Roles, que podem ser interpretadas como Classes Abstratas. em geral quando vc quer sobrecarregar um metodo, vc o quer pq vai roda algo antes , depois ou ao redor, nesse caso usar os hooks before, after ou around faz bastante sentido. se eu sei a ordem onde esses hooks são aplicados, então eu posso pegar um metodo salvar e simplemente adicionar regras ao redor de acordo com o que eu preciso.

por exemplo, vc quer uma metrica de quanto tempo isso demora: um hook around para monitoramento.

vc quer colocar log antes dizendo quem invocou o metodo e com que parametros

vc quer verificar se os parametros estao corretos

vc quer corrigir se algum parametro faltar ou estiver fora do formato adequado

vc pode querer interceptar o metodo e enviar uma mensagem a uma FILA DE MENSAGENS ( como via RabbitMQ) que vai tratar de executar esse codigo em outro lugar

vc pode querer executar um metodo em alguns momentos e em outros não ( uma parte do seu sistema esta com dificuldades e vc pode perder dados )

vc pode querer enviar os argumentos para um Redis ou ElasticSearch de forma a, caso de um erro bizarro no servidor, ser capaz de reproduzir o mesmo atraves dos argumentos usados.

vc pode querer interromper um metodo pois ele demora demais

enfim existem muitas, mas muitas aplicações.

eu tenho um exemplo que usei recentemente: eu preciso utilizar uma API e eles so admitem um request por minuto ou serei banido ( longa historia ). o codigo para usar esta API é compartilhado e é reusado em outros componentes e outras APIs mas só essa tem essa restrição. surge outra API que tem restrição de 5 minutos. etc. vale vc colocar um hook “around” para tentar executar o codigo e caso nao possa ( imagine um lock distribuido ) eu envio os dados para uma fila e eles serao consumidos num proximo momento.

vc vai dizer “mas existem PATTERNS para isso”. sim. mas se existe uma biblioteca que me oferece isso sem ter que desenvolver um proxy, strategy, chain of responsibility, etc, eu vou usar uma biblioteca que pode deixar o meu codigo mais “expressivo”.