Muito bom artigo, demonstrando que SOA não é dependente de apenas uma Tecnologia. Quantas vezes ao perguntar paras as pessoa o que é SOA elas falam que é WebService. Mas SOA também não é só ferramentas, frameworks ou código fonte. É necessário um forte comprometimento do donos do negócio, definindo o serviços que realmente possuem valores agregados, senão ao invés de SOA, iremos ter apenas um sistema de integração entre sistemas.

Abraços!

Obrigado pela resposta!

Tudo que você menciona é a pura verdade, para bom programador meia palavra basta! rs

Fazendo jus a frase “Use com parcimónia!” rs

Abração,
Paulo.

Por exemplo:

public class RegexService {

private Pattern pattern;

public void init() {
RegexComposer composer = …
…
pattern = composer.compile();
}

public boolean validate(String s) {
return pattern.matcher(s).matches();
}

}

Este tipo de abordagem é muito comum em ambientes gerenciados (exemplos disso são o spring (init-method) e EJB (@PostConstruct)). Além disso, após o pattern.compile() os objetos que compôe o RegexComposer serão elegíveis a serem coletados pelo GC. Desta forma, você tem a legibilidade da maneira fluente e a performance só será maior (na maneira tradicional) ao executar o init, que será executado apenas uma única vez. É claro que se você precisa de algo muito simples, realmente não iria valer a pena, mas em casos mais complicados a legibilidade e a produtividade que uma API dessa pode proporcionar é um argumento que, no mínimo, deve ser levado em consideração na hora da escolha.

Obrigado pelos comentários.

Abraços.

Meus parabéns, gostei da escrita.

A respeito do assunto, que é um tanto controverso, tenho a dizer que este artigo ficou muito bom para demonstrar o uso de uma API fluente. Mas acredito ser inviável utilizá-la para compor uma expressão regular.

Os argumentos que o Pedro questionou acima tem fundamento, principalmente pelo fato do “OverLoad” necessário para se mapear as características de um linguagem de expressão regular em uma API fluente.

Pensando sobre o assunto acredito que seja um problema grande utilizar expressões regulares, pela dificuldade que elas trazem em sua compreensão.

Não tenho uma opinião de qual maneira devemos implementar uma expressão regular para obter o melhor dos mundos, apenas estou tendo uma visão crítica sobre seu artigo. Espero que me entenda. rs

Grande abraço,
Paulo.

Acho a ideia viável principalmente pelo motivo que você mesmo citou, o programador não precisa conhecer a fundo expressões regulares para montar e principalmente LER/ANALISAR uma expressão.

Mas tenho algumas questões a levantar:

Acho que quando optamos por usar esse tipo de API temos que levar em consideração que estudar a API será mais rápido do que entender como escrever a sintax da expressão regular, de toda forma o maior esforço ao criar a expressão é identificar o padrão a ser procurado.

Outra questão que acho que deve ser estudada é o desempenho, expressões regulares por sí só já são custosas em termos de sistema e quanto maior a complexidade maior o tempo de processamento, dependendo do caso acredito que é mais interessante decompor a expressão e depois concatenar para montar o Pattern do que utilizar uma API fluente, principalmente quando vc tem certeza que o código que está sendo criado vai precisar de pouca manutenção no futuro.

Bom trabalho,

Abraços
Pedro.

Você explica detalhadamente cada passo, isto é interessante, para entender o que é configurado ou adicionado.

Conseguir rodar outros exemplos utilizando richfaces e ajax, depois que li este post. Valeu Henrique, meus parabéns.

=)

:-}