Classes especialistas

Vocês já criaram alguma classe especialista, para tratar de um tipo específico de tecnologia? Por exemplo, a classe abaixo, que lida com SQLs complexas e otimizadas (implementações excluídas):

[code]public class FastSqlQueries {
public Map<TestCase, Integer> getTestCaseTotalsByPlan(TestPlan plan) {
//Código com um monte de SQLs
}

public List&lt;TestCase&gt; getTestCaseByComplexCriteria(ComplexCriteria c) { }

 public List&lt;Date, TestSession&gt; getHistoricalSessionInfo() { };

}[/code]

Claramente, essa é uma classe muitíssimo pouco coesa. Entretanto, eu notei que classes assim podem ser benéficas quando separam um código extremamente especialista (SQLs complexas, escovação de bits, etc) e, ao mesmo tempo, torna menos complexas as classes de negócios.

Um outro exemplo dessa situações foi a seguinte. Tivemos de implementar um protocolo, com diversas mensagens de um padrão proprietário (que não estava sob nosso controle), vindas da central (que é implementada em C). A decodificação das mensagens inicialmente era feita em pequenas classes “decoders”, que usando polimorfismos e afins, lia os dados do ByteBuffer e instanciava objetos que representavam as diversas mensagens do canal em uma maneira OO e compatível com Java.

Pois bem, os problemas foram drasticamente reduzidos quando simplesmente separamos a escovação de bits para uma classe chamada “MessageDecoder”, que recebia os ByteBuffers do canal e gerava os tais objetos. Nossos escovadores de bits profissionais e especialistas em protocolo (de uma cultura C), ficaram extremamente satisfeitos com a nova abordagem. Deixamos a complexidade encapsulada e na mão deles. Outra vantagem observada é que o código da decodificação do protocolo ficou “próximo”, e não espalhado pela hierarquia. Quem já trabalhou com escovação de bits sabe que observar os dados de perto é muito interessante.

Seria a estratégia “vamos complicar em um só lugar, para não complicar em todo lugar”. :lol:

Alguém concorda? Discorda? Tem uma alternativa melhor?

Uns tempos depois, li num livro do Craig Larmann uma dica parecida, mas mesmo ali o autor me pareceu expressando uma opinião pessoal dele.

Isso se chama “divisão de tarefas” - deixe essas coisas difíceis e especializadas segregadas para quem sabe lidar com elas. A parte de criptografia de nosso sistema, por exemplo, ficou toda comigo e está em um único pacote do sistema.

[quote=ViniGodoy]Seria a estratégia “vamos complicar em um só lugar, para não complicar em todo lugar”.

Alguém concorda? Discorda? Tem uma alternativa melhor?[/quote]
Já precisei fazer isso tbm… e assim como o thingol falou, tinha um pacote específico para a escovação de bits, quando necessitava de mais de uma classe por exemplo, para funções/tarefas diferentes claro.

Não deve ser o mais bonito com certeza, mas principalmente pra manutenção posterior (que vc não tem a menor idéia de quem fará) é mais simples vc ter essas coisas ali separadinhas evitando destruições maiores.

Você descreveu um Mapper: Transformar dados de formatos diferentes, seja semanticamente ou em formato, é papel de mapeadores como DAOs (Objetos &lt-&gt SQL) e Servlets (HTTP Request -&gt Objetos De negocio -&gt HTTP Response).

Sim, exatamente. Mas havia mappers em ambas as abordagens que eu descrevi acima.

A questão aqui estava em criar diversas e pequenas classes mappers, de alta coesão, mas mantendo o código especializado espalhado, ou criar alguns mappers menos coesos, restringindo os pontos dos códigos muito especializados.

Então, como isso é um Mapper a literatura (Fowler/Evans/Core Paetterns) vai te ajudar nesta decisão mas basicamente isolar a transformação de um modelo em outro em um ou mais componentes específicos é uma boa coisa.

Faça a analogia com o DAO, que também é um mapper, e compare seu uso a espalhar SQL pelo código.

Desta forma eu poderia ver o controlado do MVC como um Mapper? Pois ele extrai os dados da Visao e os transforma em objetos de dominio.

[]s

Desta forma eu poderia ver o controlado do MVC como um Mapper? Pois ele extrai os dados da Visao e os transforma em objetos de dominio.

[]s[/quote]

Depende do MVC. Algo atrleado ao HTTP como Struts 1.x sim, algo onde suas ações recebem objetos e não HttpRequest/Response, como o VRaptor, não.

Eu tambem estive numa situacao parecida e conclui que uma implementacao estilo procedural era mais adequada para um Mapper que tratava um protocolo de comunicacao.

No inicio pensava numa cadeia de handlers que tratavam de cada passo do protocolo, estilo CoR, mas isso virou um ravioli desgracado. Eu ando pensando que codigo nas bordas de um sistema OO em geral nao se presta muito a uma decomposicao em objetos tradicional; outros paradigmas sao mais proximos da natureza do problema.