Chaves estrangeiras são inimigas do seu modelo OO

Bom, certamente o que eu estou falando não é nenhuma novidade, e nem fui eu que descobri isso ou falei isso pela primeira vez. Entretanto, devido à quantidade de vezes que eu já vi a utilização de atributos de classes para representar chaves estrangeiras (Foreign Keys – FKs), quis comentar isso por aqui para dar meus palpites.

Chaves estrangeiras são componentes importantes de um bom modelo de banco de dados. Elas são muito úteis no controle da integridade referencial e também são usadas com freqüência para indexar tabelas. Porém, não devemos nos esquecer que elas fazem parte do modelo relacional de dados, e não existem em um modelo orientado a objetos.

Esse assunto me veio à cabeça essa semana, quando eu estava analisando algumas coisas na JPetStore, a aplicação de exemplo do Ibatis, e que possui algumas das famigeradas chaves estrangeiras no modelo de domínio. Bom, se até projetos da Apache fazem isso, não me surpreende a quantidade de aplicações que já vi com uma porção de atributos long qualquerClasseReferenciadaId.

Pois bem, eu me lembrava de ter visto essa aplicação Pet Store em mais algum lugar além do Ibatis. Após uma breve pesquisa, encontrei de novo a aplicação da lojinha de bichinhos feita em Java, no catálogo de Blue Prints Java EE 5.

Claro que imediatamente baixei a aplicação e fui olhar as classes de domínio. Tamanha foi a minha surpresa ao constatar que também nesta implementação existem vários exemplos de atributos representando FKs. Na classe Product há um belo String categoryId. Na classe Item há um belo String productId. Achei curioso que nesta mesma classe Item há um atributo SellerContactInfo, que é uma outra classe de domínio, com atributos coerentes. Eles podiam ter colocado um atributo String contactInfoID, mas em vez disso colocaram a classe efetivamente. Ou seja, dentro de uma mesma classe há políticas diferentes de uso das FKs.

Me deixou um tanto desapontado ver isso num catálogo de Blue Prints (boas práticas). Provavelmente muita gente toma esses Blue Prints como referência de implementação, então isso me esclareceu um dos motivos pelos quais as FKs estão tão difundidas em modelos de domínio por aí.

Eu estou ainda com 2 vouchers da Sun que pretendo usar na certificação SCEA. Quando eu comprei esses vouchers eu achei que fosse usá-los na certificação de EJB 3 e na de Web Services, porém não estou animado para fazer nenhuma das 2, então me decidi pela prova de arquiteto.

Dentro do conteúdo da certificação de arquiteto está esse tipo de coisa dos Blue Prints, catálogos de padrões de projeto, entre outras coisas. Isso me lembrou mais uma vez que temos sempre que ler as coisas com olhar bastante crítico, para julgar de fato o que podemos aproveitar e o que temos que descartar.

It’s worth saying that these Blue Prints are looking more like Brown Prints, and some annoying smell is coming from them…