Pesquisar

sexta-feira, 14 de agosto de 2009

Minhas::Commons::Lib::Utils > Apache::Commons

Por mais que existam frameworks como Jpa, Jsf, Ruby On Rails, Lucene, Spring e outros, provavelmente sempre existirá uma característica ou um pedaço de código que nós desenvolvedores iremos criar e guarda-los em um modulo (pacote...) de utils. Há alguns desenvolvedores que mesmo conscientes de que já existem frameworks de ORM, criam seus próprios produtos. Acredite ainda existem.

Se você é aquele que segue a idéia de não reinventar a roda tente sempre, antes de criar essas "libs", verificar se já há algum código criado pra tal problema.

Pensando nesses problemas a grande Apache criou vários projetos com um subnome de Commons. (tanto para plataforma Java quanto .NET) E são esses projetos (não todos, só alguns) que vou resumir aqui seus usos, a idéia não é dar um guideline de uso dos projetos mas apenas mostrar que para quase toda "vontade" de criar uma lib, já existe uma pronta. Então a use...

Tenho um problema de desempenho que acho que resolveria se mantivesse alguns objetos pesados no pool..

Primeiro tenha certeza de onde está o seu real problema de desempenho, isso você só consegue medindo... dá-lhe profiler. Às vezes não são os poucos objetos pesados, mas a grande quantidade de pequenos repetidos! Bem para esse problema a Apache já criou projeto :) Apache Commons Pool.

Trabalho numa empresa que desenvolveu um sistema para o TRE-XX e lá nos temos que validar títulos de eleitor, isso eu dúvido que apache tenha...

Realmente a apache (eu acho que não, vai saber?!...) parece não ter, mas a Caelum desenvolveu (e está evoluindo) um Framework chamado Stella (http://stella.caelum.com.br/core-formatters.html), justamente para prover soluções para problemas que nós desenvolvedores Brasileiros enfrentamos diariamente, tais como: validar cpf, boletos de bancos nacionais, formatar cnpj e etc.

Pô, uso a API padrão do Java (6) no que tange ao assunto de coleções mas não consigo encontrar várias operações que gostaria de fazer com essas coleções... e ai?

Aqui o conselho seria primeiro dar uma boa olhada nas classes Collections (não a Interface Collection) e a Arrays, elas já provem bastantes características mas se mesmo assim não se der por satisfeito pesquise e irá econtrar uma Collection-Commons (http://commons.apache.org/collections/userguide.html) da Apache.

Tô trabalhando num sistema legado e aqui, por questões de performance, uso o JDBC e tenho que criar, mapear e fazer n coisas de banco, tudo na "mão"...

Performance ... sempre deve ser medida pra ser confirmada. A Apache (novamente) tem um projeto DBUtils (http://commons.apache.org/dbutils/examples.html) que têm várias funcionalidades para manuseio de banco de dados.

Nem sempre as utils vem para só para resolver problemas, às vezes criamos utils para facilitar nosso código.

Pensando assim a Apache também criou uma outra Commons (http://commons.apache.org/io/description.html) para IO, o que torna uma tarefa entediante de ler os bytes de um InputStream numa simples tarefa.

Tarefas como mandar email, realizar operação matemáticas complexas, usar recursos e protocolos das redes de computadores, já estão implementadas, testadas e sendo usadas em produção por várias pessoas.

Por último, pare e pense: porque será que grandes projetos, tais como Hibernate Core ou Search, Spring e outros, tem dependências de grande parte dos projetos xyz-commons-kwq.zip da apache? será mesmo necessário criar aquela util ou mesmo criar uma exceção para dizer que o argumento passado à um método veio nulo?

quarta-feira, 12 de agosto de 2009

Tiny Types não são desperdícios

Tiny Types são importantes por diversos fatores dos quais me lembro de: enriquecimento do domínio, forçagem de tipagem, clientes das classes perdem o poder de errar no uso incorreto da ordem dos parâmetros de algum método.

O que é um tiny type?

Sabe aquelas propriedades que costumamos definir como simplesmente String (nome, sobrenome, cpf, cep) , alguns desses atributos podem acabar se transformando em um tipo próprio.... os tiny types.
Definição: São objetos pequeninos (dahhh) que normalmente são imutáveis e seguem o padrão VO (de Martin Fowler), podem parecer chatos no inícios para alguns mas se mostram poderosos com o passar do tempo.

E as vantagens??

Enriquecimento do domínio: new Pessoa(new Nome("Luiz"), new Sobrenome("Inacio"))
Diminuição de erros: tendo uma classe qualquer Pessoa com atributos nome e sobrenome como String poderia nos permitir fazer coisas como: new Pessoa("Inacio","Luiz")

E as desvantagens???

Claramente você terá mais trabalho para definir e até mesmo mapear (seja o @Embebbed do padrão JPA ou seu mapeador próprio ou seu framework predileto para mapeamento ORM) esses mini-tipos que serão incorporados a um objeto maior.

ps: inspirado (entre outros...) pelo post da caelum.

terça-feira, 11 de agosto de 2009

JRuby, Abobrinhas e DDD

Programação funcional, linguagem dinâmica, duck typing, closures, fluência, dsl, behavior, tipagem inferida... são assuntos recorrentes das rodas dos desenvolvedores mais cool. Em uma dessas rodas ouvi a seguinte afirmação sobre o JRuby:
"Eu não gosto do JRuby... gosto do Ruby puro, JRuby é apenas os problemas do Java no Ruby"
Isso foi numa roda de "experientes em Java"... claro que tentei explicar que a frase não fazia muito sentido e que deveriamos pensar em Plataforma... e que JRuby é uma implementação para o interpretador de Ruby e não uma linguagem, que era até mesmo mais rápido do que o MRI (ou CRuby para os mais intimos), dai que eles se renderam e entenderam o que era o JRuby e MRI. Eu ainda curioso, perguntei como tinham chegado aquela conclusão, e para minha surpresa um me disse que foi porque veio com NetBeans e por isso não deveria ser coisa boa... (pode? rsrsrsrsr)

Hoje também li um post (ótimo por sinal) do Rodrigo Yoshima (AsperCom) no qual ele discorre o já batido (mas nunca esgotado) assunto Repositories... ele escreveu uma frase ("Não é uma opção arquitetural, somente estou transparecendo o domínio.") que me fez lembrar mais uma vez da falta de cautela dos desenvolvedores ao se preocuparem muito mais em tecnologia do que com a realidade. Certa vez estava realizando um projeto (não UML, na definição das classes mesmo) no qual dividi uma entidade em dois conceitos mas que tinha somente uma tabela no banco, quase 100% das pessoas me criticaram por estar sendo muito purista, naquele momento não sabia exatamente o que dizer à eles mas lembro que o sentimento era que eu estava apenas transcrevendo o que houvi dos usuários.