Fragmental

Recentemente tive um debate interessante com o Vitor Pamplona no blog dele sobre se o Prevayler oferece uma OO razoável ou não. Hoje estava passeando pelo repositório do java.net quando resolvi baixar o JavaFreeCMS e dando uma olhada rápida nos fontes confirmei que não é porque você tem uma plataforma (persistência, linguagem, VM, etc.) de objetos que você tem objetos.

O Prevayler te induz a um modelo de persistência baseado em Commands. Commands são classes que representam uma unidade de trabalho, como um algoritmo. Na maioria dos casos os Commands viram erroneamente TransactionScripts, que são alternativas muito interessantes para sistemas simples mas são antagônicos a um Domain Model.

Num TransactionScript estruturas de dados são manipuladas pelo algoritmo do Command, o que nós já conhecemos como domínio anêmico. Num Domain Model objetos ‘de verdade’ cooperam para atingir a um fim (implementar um caso de uso/user story).

O exemplo abaixo mostra como um código procedural pode ser produzido neste ambiente:


public class PostComment extends CMSTransaction {
.
public static final long serialVersionUID = 1L;
.
private long idNew;
private Date date = new Date();
private long idComment;
private String desc;
private String author;
private String authorName;
private String page;
private String email;
.
public PostComment(long idNew, String desc, String author, String authorName, String page, String email) {
this.idNew = idNew;
this.idComment =0;
this.desc = desc;
this.author = author;
this.authorName = authorName;
this.page = page;
this.email = email;
}
.
public PostComment(long idNew, long comment, String desc, String authorName, String author, String page, String email) {
this.idNew = idNew;
this.idComment = comment;
  this.desc = desc;
this.author = author;
this.authorName = authorName;
this.page = page;
this.email = email;
}
.
public void executeOn(CMS cms) {
New news = (New)cms.getModule(CMS.NEWS).getItem(idNew);
.
if (news == null) {
return;
}
Comment item = prepare(cms, news, date);
}
.
public Parser getParser(Wiki wiki) {
  return FormatPrevalenceFactory.createDefaultParser(wiki);
}
.
public Comment prepare(CMS cms, New news, Date date) {
Parser parser = getParser(cms.wiki());
.
// Creating the text and identifyng wiki words.
Text textObject = new Text(author, date);
parser.parseText(desc, textObject);
.
Comment comment = news.getComment(idComment);
.
if (comment == null) {
comment = new Comment(0, date);
}
.
comment.setAuthor(author);
comment.setAuthorName(authorName);
comment.setEmail(email);
comment.setPage(page);
comment.setDesc(textObject);
.
news.addComment(comment);
.
return comment;
}
.
}


E qual o problema com este código? Perceba que as estruturas de dados são manipuladas pelo Command que é a classe PostComment. Primeiro se cria o objeto:


// Creating the text and identifyng wiki words.
Text textObject = new Text(author, date);
parser.parseText(desc, textObject);
.
Comment comment = news.getComment(idComment);
.
if (comment == null) {
comment = new Comment(0, date);
}


Depois se popula o objeto com dados:


comment.setAuthor(author);
comment.setAuthorName(authorName);
comment.setEmail(email);
comment.setPage(page);
comment.setDesc(textObject);


Mais a frente dizemos ao objeto o que fazer:

news.addComment(comment);
return comment;


O que acotnece se precisarmos criar um objeto exatamente como o fizemos, porém precisamos que a descrição seja, digamos, precedida por um disclaimer do tipo: “o Forum não se Responsabiliza pela opinião deste usuário”? E se precisarmos fazer isso apenas para usuários da nossa blacklist?

Pelo andar da carruagem vamos criar uma outra classe de Command que faz exatamente o que esta faz mas muda uma linha:


comment.setAuthor(author);
comment.setAuthorName(authorName);
comment.setEmail(email);
comment.setPage(page);
.
if(blackList.contains(author)){
comment.setDesc(DISCLAIMER+textObject);
}else{
comment.setDesc(textObject);
}


Claro que podemos refatorar o Command para que vire um TemplateMethod e esta pequena modificação vire um hook mas… e se precisarmos criar um Comment em outro lugar, digamos quando os dados vêm de uma conexão na rede, ou um WebService REST? Fazemos a classe que cuida disso estender o Command?

O problema neste caso é que a responsabilidade pela criação do objeto não está no lugar correto. Imagine que ao contrário do que temos hoje o objeto Comment tivesse suas próprias regras de negócio (afinal, objetos são dados+funções, estado+comportamento). Ao criar um objeto Comentário ele já se popularia com os dados passados no construtor (o que, aliás, evitaria quebrar a invariante deste objeto, o que acontece no exemplo acima) e que para criar um comentário com disclaimer seja tão simples quanto criar uma subclasse chamada DisclaimeredCommet, que já traz a lógica de negócios. Podemos ter algo como:


Comment newOne = commentFactory.createComment(author, text);


E na Factory:

public Comment createComment(Author author, Text text){
.
Comment created=null;
.
if(blacklist.contains(author)) {
created=new DisclaimeredCommet(author, text);
} else{
created=new CommonComment(author,text);
}
.
return created;
}


A lógica sobre qual comentário criar ficaria no objeto responsável pela criação (a Factory) e não por 500 outros objetos. Para quem exibe não existe diferença entre CommonComment e DisclaimeredComment, eles são instâncias de Comment (Zahl abençoe o polimorfismo). Não importa onde fosse chamado, o código sempre iria produzir o objeto correto.

Claro que este exemplo poderia ser resolvido de mil maneiras diferentes mas é só um exercício sobre pensamento procedural x orientado a objetos. Na verdade nem pensamento procedural porque mesmo este paradigma tem meios para evitar os problemas citados (mais sobre isso em outro post). Mas não se engane: o problema não é o JavaFree, seu CMS muito menos quem o implementou. Só está aqui porque é o único proejto em produção que eu conheço (e tenho acesso aos fontes) usando Prevayler. Se quem criou este design o fez assim fez porque a cultura que impregna nossa comunidade, academia e mercado não é OO. Este mesmo problema acontece em zilhões de outros projetos livres (inclusive de outros fóruns e CMS), projetos comerciais e mesmo em simples exercícios de faculdade.

O problema dos bancos de dados relacionais já foi quase que completamente resolvido com ORMs eficientes como Hibernate e JPA, o problema ainda é, como era há 30 anos, fazer com que os sistemas sigam uma modelagem OO. Como fazer com que as pessoas entendam que objetos não são containeres de dados e sim entidades ‘vivas’ em um sistema. Muitos pensavam que ter uma plataforma OO amplamente difundida faria isso acontecer. java mostrou que falharam. Outros pensaram que ter um SGBD relacional é o problema, tirar o SGBD faz os objetos fluírem, o código acima mostra o contrário.

O problema não é na plataforma, é na cultura.

This entry was posted on Thursday, May 10th, 2007 at 11:57 pm and is filed under arquitetura, bancos.de.dados, comunidade, engenharia, foss, java, orientacao.a.objetos, programando. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.