Ando muito insatisfeito por ter que abrir mão do paradigma orientado a objetos (OO). Não é um caso das segundas-feiras e também não é uma crise existencial causada pelo tipo mais chato possível de software que alguém poderia trabalhar com: sistemas de informação.
O problema é que a empresa onde trabalho insiste em fazer sistemas procedurais, o que é esquisito, já que o termo “orientação a objetos” é citado em e-mails, declarações de escopo e reuniões com nossos clientes. Nossa própria metodologia de desenvolvimento não faz sentido para o paradigma procedural. Será meu trabalho um grande faz-de-conta?
Vejam só: um objeto, no paradigma OO, é algo que tem estado e comportamento. Qualquer modelo de classes de domínio de qualquer projeto daqui não tem comportamento.
Sem atribuição de responsabilidades aos objetos, a modelagem é banal. Se fôssemos dar nomes às associações nesses modelos, todas elas se chamariam “Contém”. Dificilmente vai além disso. Objetos contém outros objetos e esses contém outros e assim por diante. No final é um diagrama que serve apenas para mapear um banco de dados e não é um modelo OO que abstrai de forma elegante um problema do mundo real. Esses modelos são conhecidos como Anêmicos na comunidade de desenvolvimento.
Se o comportamento não está em nossos objetos, está onde? Estamos implementando rotinas em camadas de serviço e em pretensiosos Business “Objects”. Estamos entrincheirados em um mundo de processamento de dados, sem conseguir enxergar a realidade. Nem os nomes dessas rotinas tentam esconder a sua natureza, como os muito comuns “pesquisar()”, “processar()”, executarRegraNumeroX()”, etc. Para fazermos OO, precisaríamos de métodos e não rotinas, precisaríamos de mensagens e não chamadas, atributos e não campos.
A maioria dos padrões de projeto OO, como os do GRASP e do GoF, simplesmente não são aplicáveis nos nossos modelos de negócio. Chega a ser cômico.
Mas alguém poderia argumentar que o paradigma estruturado/procedural é melhor para sistemas como os nossos. Nesse caso eu teria que discordar. Orientação a objetos surgiu para resolver o problema da complexidade. E a complexidade dos sistemas geralmente aumenta mais que o seu tamanho. Polimorfismo, herança e encapsulamento tanto de dados quanto de comportamento são artificíos da orientação a objetos que servem justamente para lidar com a complexidade. E isso é algo desejável em projetos grandes e com prazos apertados como os nossos. Fora que ainda não vi nenhum projeto aqui onde o processamento dos dados fosse um desafio maior que os complicados relacionamentos entre os inúmeras entidades de negócio dos clientes.
Segundo Chris Richardson, em seu livro POJOs in Action, quandos algum dos seguintes casos for verdadeiro, a lógica de negócios poderia ser escrita de forma procedural: quando a equipe do projeto não tem as habilidades necessárias para projetar OO, quando as regras de negócio são muito simples e quando não se está usando um framework de persistência.
Se for o caso de continuarmos fazendo sistemas desta maneira, então ao menos deveríamos adotar as técnicas apropriadas. Análise e Projeto OO, como sugerido pela nossa metodologia, poderia ser substituída por Análise Estruturada. Afinal, diagramas de sequência da UML são úteis para distribuir responsabilidades em um domínio de objetos e não descrever processamento de dados, algo que DFDs, DDs, DERs e DTEs da Análise Estruturada supostamente fazem melhor.
Não é particularmente horrível criarmos sistemas procedurais, tanto que funcionam e são uma constante no mundo JavaEE. Todos os garotos legais estão fazendo isso. Apesar de que seria menos chato se fizéssemos OO. Com EJB2 nem dava pra tentar fazer diferente. Mas esse cenário está mudando, tanto que os objetos no EJB 3.0 passaram a ser POJO e, sendo assim, podem ser usados para criar modelos ricos OO. Impecilho técnico não existe. O problema é cultural.
