Texto escrito em 2013
Raríssimas vezes me deparo com uma equipe questionando se deve ou não adotar orientação a objetos em seus novos projetos. Dado que sabemos não existir bala de prata em software este é o tipo de comportamento que levanta minhas antenas para a possibilidade de sermos vítimas de determinismo linguístico. Será?
No mundo dos bancos de dados talvez o evento mais importante das últimas três décadas tenha sido a popularização das bases de dados NoSQL, que trouxeram à tona o questionamento a respeito do escopo em que os bancos de dados relacionais deveriam ser aplicados. Até então a crença de que o modelo relacional deveria ser aplicado a qualquer situação imperava. E com isto soluções que poderiam ser implementadas com facilidade em outros modelos eram executadas a duras penas em um formato que não lhes servia. Me pergunto portanto o seguinte: será que esta nossa fé cega na orientação a objetos não estaria nos causando o mesmo tipo de problema? Será que não deviamos criar um movimento NoOOP (Not Only por favor)?
Temo que a orientação a objetos tenha nos cegado para as outras opções. Prova disto é que muitas vezes quem levanta questionamentos contra o paradigma (como estou fazendo agora) é automaticamente rotulado de retrógrado, ingênuo, etc. Sendo assim, antes de continuar, gostaria de pedir ao leitor que evite a postura do mal artista.
Síndrome do mau artista
Sou a ovelha negra de uma família composta massivamente por pintores e escultores. Neste meio é muito comum a postura do mal artista. É fácil detectá-la: é aquele sujeito que tem uma obra completamente hermética (e portanto ruim, visto que não consegue comunicar nada) e que rotula todos os que a questionam de insensíveis, incultos, ignorantes, etc.
O mesmo vejo acontecer na nossa área de TI. Aliás, já até escrevi sobre isto ao abordar a questão dos fan boys. Sendo assim por favor tenha a mente aberta ao ler este post, mesmo por que vou levantar aqui muito mais perguntas que respostas ok? Na realidade, eu não acredito que o problema esteja na OOP em si, mas sim no uso forçado desta.
Jogando o ouro fora
Em diversas consultorias que dou topo com a mesma situação: uma equipe composta por bons programadores que devem ser reciclados (odeio quando usam este termo) para uma tecnologia mais moderna. Normalmente vêm na forma de alguma linguagem orientada a objetos. E então começam aquele processo nojento de substituir software legado que funciona por software escrito do zero na linguagem OOx (Joel Spolsky tem um texto maravilhoso sobre isto) que pode terminar na demissão de um ou outro funcionário e que SEMPRE mina a auto estima dos desenvolvedores mais antigos.
Nestes momentos eu sempre me pergunto o seguinte: se você já tem algo que funciona bem por anos, que tipo de vírus é este que invade a mente dos gestores que os leva a jogar fora a prata da casa? Ei, eu sei: hype. Eu fico impressionado como nestes casos uma equipe composta por profissionais talentosos é trocada por outra que, na maior parte das vezes, será no máximo medíocre. Os novatos podem até mesmo ter uma visão técnica mais avançada sobre a nova tecnologia imposta (normalmente tem), mas o que realmente importa, que é o conhecimento por trás dos problemas que precisam ser resolvidos, não.
Então pergunto: se sua equipe tá trabalhando BEM com uma linguagem procedural como PL/SQL ou alguma outra de negócio, realmente é necessário trocar a tecnologia e, com isto, transformar sua equipe experiente em um bando de estagiários? Este é meu primeiro questionamento. E esta experiência que tenho é a base pro resto deste post.
Qual complexidade importa? A questão dos verbos
No desenvolvimento de software há duas complexidades. A primeira é inerente ao problema que precisamos resolver. Não há muito o que possamos fazer a não ser estudar ao máximo sua natureza. A segunda diz respeito à dificuldade na implementação da solução, que normalmente piora de acordo com nossas escolhas mal feitas.
Observando o pessoal que trabalha com ADVPL, Clipper, VB, Power Builder, Delphi, PHP de forma estruturada fico maravilhado com o fato de serem equipes extremamente produtivas sem precisarem se preocupar com coisas que nós, que trabalhamos com OO lidamos o tempo inteiro, como por exemplo padrões de projeto, encapsulamento, etc. Os caras se dedicam apenas à implementação da solução do problema, e isto não quer dizer que o software gerado é ruim. (vocês sabem que existe sistema feito sem orientação a objetos bom por aí né? :) )
Observando o código fonte fica claro que ele expressa BEM o modo de pensar do programador: foco no verbo. Yeap, quando planejamos uma ação, não pensamos nas entidades que precisam ser implementadas, mas sim nas ações que precisamos tomar. Na abordagem puramente OO vêmos o pensamento contrário: o sujeito primeiro projeta as suas classes e DEPOIS o que elas fazem (Steve Yegge tem um texto excelente sobre isto). O modo de pensar OO primeiro vê os substantivos: só depois os verbos. Será que isto é uma coisa boa? Será que não está a nos levar para uma solução mais complexa do que precisamos?
Algumas das perguntas que escuto em consultorias em um primeiro momento podem parecer tolas em sua superfície, mas expõem muito bem o mau uso da OO. Seguem algumas:
- Meu trabalho aqui consiste na maior parte das vezes em criar novos relatórios. Por que eu estou sendo obrigado a aprender padrões de projeto? Será que o padrão de projeto não é uma solução para deficiências da própria orientação a objetos?
- Se pra obter os dados a partir do banco de dados eu tenho SQL, por que eu preciso usar uma ferramenta ORM? Sério que eu preciso implementar um DAO???
- Por que as minhas classes não tem nome de verbo? (yeap: esta parece tolice mas tem uma profundidade incrível)
Ignore seu arsenal de boas práticas por um momento e ponha-se no lugar de alguém saindo do mundo procedural para OO. Você verá que são perguntas muito justas.
Sintoma: as classes desnecessárias
Sabe uma coisa que sinto falta no Java? Structs. Ao ler código Java diversas vezes topamos com classes usadas para representar um registro no banco de dados como a abaixo:
[code lang="java"]
class Pessoa {
private String nome;
private String sobrenome;
private Date dataNascimento;
public String getNome() {return this.nome;}
public void setNome(String valor) {this.nome = valor;}
// e mais getters e setters para os demais campos
}
[/code]
Na maior parte das vezes são usadas APENAS para expor informações em uma tela ou relatório. No segundo caso é pior ainda: são instanciados centenas, milhares de objetos com o único propósito de exporem estes dados. Nestes momentos me vêm à mente o seguinte questionamento? Eu REALMENTE precisava representar estes dados como objetos? Será que não seria mais fácil se eu tivesse usado algo como uma estrutura, visto que o encapsulamento aqui não possui utilidade ALGUMA? Se formos levar em conta o custo computacional de se instanciar um objeto, a questão passa a ser ainda mais significativa. (sobre getters e setters, o Paulo Silveira tem um texto muito interessante que pode ser lido no blog da Caelum).
Alguém poderia me dizer que há objetos ricos e tal. Mas dado que na maior parte das vezes o uso da classe é apenas para armazenar dados, será que ter uma classe rica é realmente um ganho? Será que uma abordagem mais simples não cairia melhor, como por exemplo o uso direto de uma linguagem declarativa como SQL ou mesmo algo procedural? Cadê meu ganho? Ei: o pessoal do COBOL sabe disto há muito tempo. Não é a toa que sistemas de processamento em lote violentíssimos são implementados de maneira procedural por DÉCADAS sem serem substituídos por alguma outra coisa implementada usando orientação a objetos.
Mas a culpa é do programador!
Uma solução para os problemas que levantei acima seria apontar o dedo para o programador que não fez o seu trabalho direito. Mas aí eu me pergunto: será que ele realmente tem toda a culpa? Acredito que não. A partir do momento em que a OO passou a ser vista como bala de prata, a opção por linguagens que não siga o paradigma passa a ser vista como retrógrada, muitas vezes obrigando o profissional a usar a ferramenta errada para o problema. Yeap: não é fácil dizer não quando sua imagem ou emprego depende disto (sou kamikaze).
Dado que nas faculdades as linguagens ensinadas hoje são em sua maior parte orientadas a objetos, e criou-se o mito de que a tecnologia mais nova sempre é superior, o que vêmos na realidade é a ditadura do objeto. Se em uma entrevista de emprego você disser que não gosta de OO (justificando, é claro), suas chances de ser aprovado aumentam ou diminuem?
Me pego pensando às vezes se boa parte do código ruim que vejo por aí seria de fato culpa apenas do programador. Será que não entra aí também o fato deste se ver obrigado a usar orientação a objetos onde não devia?
Então você quer dizer que OO é horrível Kico?
Não. Apenas que atualmente estamos afogados nela de tal forma que simplesmente ignoramos por completo as demais alternativas e isto é péssimo. Se a orientação a objetos fosse tão ruim assim ela simplesmente não vingaria, mas a partir do momento em que passamos a habitar um ambiente dominado por uma única abordagem com certeza as soluções que implementamos são, devido à nossa cegueira, bem mais complexas que o necessário.
A questão não é a qualidade intrínseca do paradigma, mas sim o uso errado que fazemos dele. E dado que o mito da bala de prata já é fato conhecido a no mínimo 28 anos, me assusta ver a orientação a objetos ser tida como tal, especialmente por aqueles que se dizem tão espertos, antenados, bacanas e tal.
Quando eu não uso OO?
Se seu programa exerce uma única função, como por exemplo compactar um arquivo, você o implementaria usando OO ou procedural? E se o foco for performance absoluta, será que OO cai bem? E para o processamento massivo de dados? Um sistema matemático é melhor impelentado em OO ou em uma linguagem funcional como Lisp? As situações são infinitas, dei apenas alguns exemplos nos quais o paradigma não é a melhor opção. Não há como responder de forma geral a esta pergunta.
No entanto, há uma pergunta que nos ajuda a chegar a uma solução. Ao analisar um sistema desenvolvido em algo que não seja OO, pergunte-se: por que não OO? Por que um sistema especialista foi implementado em PROLOG ao invés de Java? Por que o MySQL foi feito em C ao invés de C++? Por que o Linux não tem C++? Por que o software de controle da minha locadora é feito em Clipper e não C#?
Um exemplo interessante do não uso de OO é no ambiente corporativo aonde as linguagens de quarta geração (4GL) como ABAP, Dataflex, Natural, PL/SQL, Progress e muitas outras são usadas de forma imperativa. Novamente vêmos a mesma situação: equipes que podem até mesmo não estar usando o que está na crista da onda, mas que atendem perfeitamente e com qualidade os requisitos da empresa. Detalhe: são situações complexas que normalmente são usadas como justificativa para a adoção da OO. Sim: este é um grande tapa na cara do paradigma.
Aliás, deixo o questionamento ao leitor: por que as linguagens de negócio como as da quarta geração não estão mais "mainstream"?
Concluindo
A Orientação a Objetos não é o problema mas sim o seu excesso. Eu poderia ficar aqui páginas e mais páginas descrevendo limitações técnicas do paradigma o que seria uma tolice. Sou mais pragmático: apontei aqui apenas os problemas de ordem mais humana que percebo na minha interação com outros programadores.
É chegado o momento de começarmos um movimento Not Only OO: valorizando as outras alternativas e, principalmente, os excelentes profissionais que estamos destruindo com nossa arrogância. Bora?
PS: meu próximo post vai ser sobre meu trabalho envolvendo assédio moral em TI. Aguardem! :)
Top comments (0)