Fragmental

O Vitor respondeu meu post, eu tentei colocar um comentário mas ficou muito grande, então vamos tentar retrucar por aqui mesmo :)

Eu entendi que ele quis dizer algo como “em >coloque -um-valor-muito-alto-aqui<% dos casos usar OO é overhead” e, como disse, concordo em parte, mas acho que mais uma vez houve uma certa ênfase errada.

Para começar, acho que mudou bastante de idéia. Em Fevereiro você disse:

Como um bom amante da Orientação a Objetos pura eu odeio os bancos de dados tradicionais e acho os frameworks de O/R um saco (além de ser uma grande gambiarra)! Por isso eu uso Prevayler. :D

Que foi o que começou este debate todo. Bom, vamos lá.

Por exemplo, com o BabaXP eu forcei a implementação de um DAO, mesmo usando o Prevayler. Achei que era possível criar um DAO OO, algo bonito, que abstraísse as diferenças entre Prevayler e um banco relacional qualquer. Me enganei. É impossível fazer algo nesse nível só por causa de uma única diferença entre as duas tecnologias, o acesso direto a memória dos dados.

Bom, Prevayler em si não é OO, como já discutimos no seu blog e em um post passado aqui neste mesmo, mas ainda que fosse não há problema em ter um Mapper (que é conceito por trás de um DAO) entre dois domínios de objetos diferentes. Na verdade, Eric Evans possui ótimos textos sobre Context Mappers no seu livro que fazem exatamente isso.

Quando trabalhei com Hibernate 2 e EJB 2, não consegui imaginar uma forma melhor de se programar do que seguir um fluxo de ida e volta: Locator -> Facade Session Bean -> Transaction -> DAO -> Hibernate Entity. Com VOs circulando entre eles. Aparentemente uma bela estrutura OO, exceto por um problema: os algoritmos continuavam seqüenciais, apenas em objetos diferentes. Os objetos não resolviam os problemas da regra de negócio, mas sim simplificavam o uso da própria tecnologia (EJB). Não haviam objetos inteligentes, apenas os JavaBeans secos, como o Hibernate 2 queria, e VOs secos, com regra de negócio pertinente ao objeto e só.

Ahm? Por que o Hibernate fazia você usar DTOs? Eu usei Hibernate com objetos de negócio nesta versão e não tive nenhum problema, poderia explicar melhor? Mesmo os tão mal-falados EJBs podem ser utilizados com objetos. Não não é tão fácil quanto em JPA/Hibernate 3, mas também não é difícil.

E não, DTOs/VOs/TOs ou como estejamos chamando esta semana não fazem um bom modelo OO, muito pelo contrário.

Uma estrutura semelhante foi criada com o JavaFreeCMS, uma arquitetura Action Based não poderia gerar outro resultado do que uma implementação Action Based, que é um nome mais bonito para implementação seqüencial. Por mais que eu quisesse implementar algo OO, tinha algo que me prendia ao modelo relacional. Cultura? É, foi sim. O JavaFreeCMS foi baseado no phpNuke, no qual é muito fácil adicionar módulos e componentes. Lá basta você adicionar um .php e criar a tabela, pronto. Tentei fazer algo semelhante, mas orientado a objetos. Acabei descobrindo que o esforço para implementar tal flexibilidade era tamanha que eu precisaria de uma equipe para desenvolver um Simples e Idiota CMS OO. Acabei chutando o balde e implementando o mais simples possível.

Foi então que comecei a suspeitar da utilidade da Orientação a Objetos e dos Design Patterns. Como falei antes, até então eu considerava que o problema era eu. Que eu era incapaz de fazer algo bom utilizando o melhor da OO e dos design patterns. Afinal, tanta gente mais experiente falava bem dos patterns e tals, alguma utilidade eles deveriam ter, não é? No entanto, hoje eu vejo que não é bem assim.

Antes de mais anda não existe nenhum vínculo entre OO e Design Patterns, um existe sem o outro. Depois, existem diversos CMS OO por aí para provar que não é bem o paradigma que tem problemas. Em boa parte deles adicionar ou remover módulos é simples, provavelmente o design que se fez para este caso do JavaFreeCMS em específico não foi adequado (aliás o Prevayler prega um paradigma Action-based em suas transações).

Não adianta você querer implementar a sua estrutura de dados com o melhor da orientação a objetos se você vai acabar migrando esses dados para um sistema relacional. Você tem um esforço considerável para identificar várias heranças, composições, agregações, relacionamentos uni e bi-direcionais e após isso mais um esforço para migrar essa estrutura para o ambiente relacional. Para variar, não existe nenhum framework de O/R que consiga mapear atributos específicos de cada abordagem sem perder em performance, em simplicidade ou produtividade. Até hoje eu nunca vi ninguém conseguir implementar um sistema completo OO e somente depois de tudo criado integrar com alguma forma de persistência de maneira transparente. A OO aplicada, com todos os seus recursos e ideologias, neste tipo de aplicação, só serve para complicar as coisas, trazer mais trabalho e problemas para o desenvolvimento.

Você está ignorando simplesmente décadas de técnicas de mapeamento Objeto-Relacional e, mais uma vez colocando problemas no Hibernate e JPA que eles não possuem. Pode explicar por que eles não fazem este mapeamento?

Segundo este conceito podemos chegar à conclusão que linguagens de Assembly foram uma coisa muito ruim, já que elas apenas adicionam uma abstração em cima do modelo “real”, de linguagem de máquina. Será que elas não trazem benefícios?

A mesma coisa pode-se dizer das aplicações request-response, que mudam de nome a cada ano, mas continuam a mesma coisa. Muitos frameworks não nos deixam fazer muita coisa da OO. Você recebe uma lista de parâmetros e devolve uma lista de resultado. Lista == tabela == relacional. Para provar, pense no seguinte, a cada resposta que um sistema como esse dá, ele carrega todos os relacionamentos de cada objeto, ou carrega apenas a parte que interessa ou que a aplicação cliente usaria? Agora outra pergunta, para isso utiliza-se VOs específicos para cada request ou um único VO com sistema de lazy loading? Implementar um VO para cada requisição é dose. Deixar por conta de um lazy loading também muitas vezes falha (ou a conexão fica aberta e bloqueia outros acessos ao banco ou ela se fecha e se o usuário pedir algum objeto, irá ter um belo “session closed”). Alguém já ouviu falar no conceito de “páginas” com Orientação a Objeto? Não né. Por que esse conceito foi criado pelos bancos de dados e implementado graciosamente com a instrução “limit” no SQL.

Acho que você confundiu um pouquinho listas de estruturas de dados com álgebra relacional. Em um programa eu posso ter listas de qualquer coisa, e elas não precisam obedecer aos princípios de álgebra relacional. Por um acaso bancos hierárquicos ou em rede não implementam listas? Por um acaso uma HashTable é relacional? Prevayler trabalha com listas de objetos, ele é relacional então, certo? Sua prova… bem, não condiz com a realidade.

2007. Faz pelo menos 3 anos que VOs são completamente desnecessários em java, se é que algum dia foram. Lazy loading funciona muito bem, obrigado. O problema de sessão aberta é contornável facilmente com algumas técnicas, apesar de sim, ser um problema real, mas nada impede que eu tenha paginação em uma consulta OO via Hibernate, basta eu fazer eager fetching (que pode, inclusive, contar com consultas polimórficas) antes.

Mas… putz…dizer que páginas foram criadas nos bancos de dados é ignorar solenemente os diversos usos de paginação em memória e outras estruturas uhm… não relacionais.

Pense na seguinte frase: Os dados saem de uma base relacional, são transformados em objetos, executam uma regra de negócio simples (Somas, médias, grupos, contatores, etc), são transformados em relacional novamente e exibidos. Esse é o fluxo de muitas aplicações web e desktop. Se é assim, para que diabos alguém adicionaria aquela transformação e destransformação para OO no meio do processo?
Não parece. É, uma coisa desnecessária. Se a regra é simples, se a arquitetura que você utiliza dificulta o processo ou se os objetivos da aplicação são “relacionais”, para que ficar inventando moda? Os Design Patterns também não escapam. Em várias ocasiões eu vi que era possível implementar padrões um pouco mais complexos diretamente na regra de negócio, como o State por exemplo. No entanto, o State é tão complexo e chato de manter que não vale apena trocar por um campo de “situação” e mantê-lo com o próprio objeto.

Sua aplicação é simples? Ótimo! Pode abrir mão do bom uso de OO e ainda assim manter uma estrutura legível e com manutenção razoável? Excelente! Só não tome isso como regra geral. Se você acredita que a complexidade de criar um programa com estruturas de dados de objetos quase nunca é justificável eu realmente não entendo o que te faz não utilizar uma linguagem que permita este design e ainda traga mais vantagens, como ASP clássico, ColdFusion, PERL+CGI ou PHP. Java pra quê?

Quanto á confusão com Patterns vou considerar respondida acima.

Obviamente, nem toda a aplicação web é tão simples assim, mas minha intuição me diz que 98% do mercado brasileiro segue essa estrutura. Apenas 2% das aplicações merecem ter boas implementações de OO e Design Patterns.

Mais ou menos concordo (mais sobre isso abaixo), mas existe um problema intrínseco aí. Como você frequentou a academia mais tempo acredito que saiba melhor que eu que existe algo chamado programação estruturada e suas variantes, dentre elas programação OO e procedural. Agora, dado que a grande bibliografia de Yourdon, Page-Jones e seus amigos mostra que fazer programas em paradigma procedural exige várias técnicas (fan-in, fan-out, coesão, divisão de módulos, controle de flags, acoplamento… lembra?) para manter um programa… hmm… editável… acho que você está saindo da programação estruturada pura e simplesmente, certo? Segundo este princípio crie classes apenas com atributos públicos sendo manipulados por funções estáticas, aliás, por UMA GRANDE função estática :P

Eu concordo em gênero, número e grau que OO pode ser um overhead tremendo quando se tem um domínio simples, e inclusive defendo arduamente o uso de DSLs simplificadas para construção de sistemas, mas simplesmente largar o paradigma OO em favor de algo que não é OO nem Procedural é retroceder para antes de Dijkstra. Só falta um GOTO.

Entre esses 2% estão, em geral, aplicações com baixa quantidade de informação do usuário: compiladores, ferramentas de BI, diagramadores de interface, toolkits gráficos, aplicações como diagramadores vetoriais, gimp, blender, engines de jogos, browsers, IDEs, etc. Aquelas aplicações de sistemas de informação que seguem a estrutura de frameworks, o estilo de linguagens ou APIs, definitivamente não precisam de mais padrões ou mais OO. Você está preso a ela, portanto faça o que ela mandar e você será produtivo, invente moda e já era! Tente trabalhar de uma forma diferente da MVC com o Swing, e você se verá enrascado. Tente transformar as entities do EJB em Business Objects e estarás f.u.d.i.d.o. :)

Sei não. Ou minha realidade é muito diferente ou a sua é meio..exótica. Nos últimos anos trabalhei em sistemas de gestão de previdência privada, billing de telefonia, análise de risco, gestão de malha ferroviária, gestão de passageiros, conteúdo multimídia, gerenciadores de conteúdo (sim! e alguns deles)… e boa parte das pessoas que eu conheço ficam com sistemas parecidos. Todos eles tinham lógica a modelar como objetos

Fiz também muito destes CRUDs simples na vida mas eles definitivamente não são 98% nem do que eu fiz nem do que as pessoas que conheço fizeram. Se alguém só faz CRUDzinhos simples que nem um Domain Model se justifica a primeira sugestão é deixar Java de lado e trabalhar com algo mais produtivo como PHP4. O problema é que sistemas crescem, se integram e mudam, e acho que é este ponto que você ainda não entendeu que um bom design, seja ele OO ou não, faz diferença.

Caindo nos bons designs você irá ver um bom design procedural e perceber que existem práticas que são melhor implementadas num modelo de objetos, como quando você precisa proteger uma estrutura de dados de acesso indevido, ou sua invariante. Foi assim que o design de aplicações evoluiu até hoje.

Concluindo, nos dias de hoje, em grande parte dos sistemas de informação, a estrutura relacional atuando sozinha é perfeita! Ninguém precisa de Objetos para tais atividades, a não ser, é claro, que você utilize um banco de dados Orientado a Objeto, aí a coisa muda de figura. Mas como muita gente tem medo deste recurso… Hoje, está bem claro para mim: Aplicações com mais regra de negócio do que informação, utiliza-se orientação a objetos. Para sistemas de informação, onde há mais dados do que regras, vai do banco. Bancos relacionais, aplicações relacionais, SQLs e etc. Com bancos OO, aplicações OO.

Isso é complicado. Se você coloca o banco de dados no centro do universo é bom colocar as regras de negócio lá também, cheia de Stored Procedures, e ficar apenas com front-ends em linguagens de programação convencionais. Do contrário o que você faz quando duas aplicações tentam compartilhar o mesmo conceito? Se eu tenho um conceito formado por um join entre duas tabelas o conhecimento sobre este formato deve ser espalhado por todas as aplicações que utilizam o conceito, e quando eu mudar a implementação das tabelas tenho que mudar TODOS os sistemas, ou criar malditas views para segurar o legado.

O modelo de SGBD como centro do universo já foi substituído há quase vinte anos, uma boa lida sobre componentes e serviços vai te dar uma luz neste tema.

No entanto, se você puder escolher que tipo de abordagem usará, saiba que o que vale é a sua intuição. Não force as coisas. Não deixe de implementar a sua estrutura OO só porque alguém te disse que deveria ser implementado o Design Pattern Xyz. Utilizando o mesmo exemplo do State, se você quer fazer uma enumeração e ficar controlando no teu objeto, faça, se achar melhor cair no mundaréu de leis do State, vá em frente. Tudo se resume a sua intuição. Se alguém disser que pode ser feito de um jeito melhor, sem atrair complexidade e dificuldade de manutenção, mande o cara refatorar o teu código e pronto! Mas, não se assuste em ver gente complicando as coisas sem a mínima necessidade :)

Sim, cada caso é um caso mas acredito que o que deve guiar a escolha técnica não é a intuição e sim a razão, derivada da experiência e estudo das diversas técnicas e práticas, arquiteturais e de design, que foram desenvolvidas pela comunidade de desenvolvedores, acadêmicos, pensadores e práticos por todas estas décadas.

Eu tenho certeza absoluta que você pode me mostrar um monte de coisas super-simples sobre sua área de engines gráficas que eu vou achar mega-complexas sem estudar o motivo pelos quais as coisas são desta ou daquela forma. Por isso que não adianta, plataforma não vence cultura.

Update:

O Vitor colocou um follow-up no blog dele. Como não traz nenhum novo argumento aos pontos aqui levantados além de fazer um bashing sem nenhum argumento concreto em cima de AOP e OO (poxa, até o BileBlog usa alguns argumentos), e cisas estranhas como “eu disse que era impossível porque não faz nenhum sentido gastar tempo e simplicidade implementando esse tipo de coisa”, questionamentos vazios como “por que HQL não implementa todas as funcionalidades da OO?” (Como se Java os implementasse…), tratar um ERP, coração de qualquer empresa, como “coisa menor”, não saber o que é eager fetching e detaching e ainda assim achar os criticar, e, principalmente, este trecho:

Shoes, pergunte para alguém das antigas se ele leu Yourdon e Page-Jones para poder programar. Não leram. Se você for olhar o fonte de alguém das antigas perceberá que tem uma organização. Não é uma OO, mas é tão organizado quanto, e certamente não baixa a produtividade da equipe. Hoje só para programar uma boa OO precisamos ler várias bibliografias, conhecer Design Patterns, e várias outras coisas que você conhece bem. Porquê? Para desenvolver um sistema onde o cara vai cadastrar e ler dados? No máximo um relatório com algumas aglutinações, somas, consultas, limites e etc?

Que me preocupa muito vindo de um estudante de mestrado (além de ser bravata, já que a maioria dos engenheiros de sistems de verdade em algum momento tiveram seu contato com análise struturada/essencial e projeto estruturado).

Eu realmente adoraria ter um debate sadio mas a falta de argumentos e o excesso de factóides, evidências anedotas, falácias e achismos não deixa. Eu realmente tentei mas fico por aqui.

Eu já vi este ponto de vista várias vezes e na grande maioria delas um pouco mais de leitura e experiência ao manter sisteminhas “simples” “de cadastro” que viraram bombas-relógio, vivem mais tempo do que deviam e têm que ser integrados, entendidos, estendidos ou meramente consertados mudaram a perspectiva. Provavelmente é só questão de tempo.