Corpo estranho: questionando a orientação a objetos

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

Sim, eu vou criticar suas pinturas ruins. :)

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

Foto de um projeto OO ultra high tech que substituiu um sistema legado que funcionava. Não é lindão?

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

Yeap, soluções não OO também podem!

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:

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
}

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!

Estes objetos ditadores...

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! :)

70 thoughts on “Corpo estranho: questionando a orientação a objetos

  1. “É interessante o teu post questionando a Orientação a Objetos como panaceia. Mas o que você não deixa claro é se você está falando em contra do Desenho Orientado a Objetos, ou das linguagens Orientadas a Objetos. Algums dos teus comentarios parecem atacar OO como método de desenho e outros parecem atacar as linguagens. Esta é uma diferença muito importante de se fazer”

    Muito bem pontuado Rodrigo. E seu post é excelente.

    Responda

  2. Opa, só para dar mais um pitaco rápido na conversa, que tá bem interessante. Lembrei agora de um indício mais recente de que OOP não é bala de prata na modelagem de sistemas (bom, nós já sabemos que não existe bala de prata mas podemos estar sofrendo daquilo que o Kico chama de “determinismo linguístico”): AOP.

    AOP surgiu porque notou-se que OOP não conseguia mapear de forma modular certas características de um projeto, aquelas que foram chamadas de “cross-cutting concerns” (http://en.wikipedia.org/wiki/Cross-cutting_concern). Nem herança nem composição dão conta desses aspectos de uma forma simples, organizada e de fácil manutenção.

    Responda

    Kico (Henrique Lobo Weissmann) Reply:

    E o interessante da AOP é que ela não se aplica apenas a orientação a objetos.

    Responda

  3. Estudo de caso: estou desenvolvendo um sistema para minha escola usando Java e O.O., (com auxíliio de um framework do Kico, o Miocc).

    Aí li este artigo, fiquei matutando… e tava revendo os meus backups velhos até achar um Delphi 7 perdido ali. Saudades… eu olhei pra ele, ele olhou pra mim, rolou aquele clima… Vamos desenvolver o sistema ali, pra ver no que dá. Resultado: 4 dias de trabalho e 10 funcionalidades prontas e testadas – claro, eu tinha MUITO código pronto e reutilizável, como um form genérico com todo o mecanismo CRUD, um TextBox de busca que abre uma grid embaixo, e um gerador de relatórios em HTML (tudo feito nos tempos em que eu trampava com o Delphão).

    Eu tendo a tentar simplificar demais as coisas, aí quando eu tento aplicar O.O. eu sempre acho que estou complicando. Vamos começar fazendo procedural. Aí começou a lógica de pagamentos de mensalidades e complicou um pouco para fazer procedural. Eram muitos parâmetros. Pronto, 4 classes e **aquela parte** foi feita em O.O. Fim! Se eu precisar da O.O., uso em outro momento.

    P.S.: ainda vou desenvolver o mesmo sistema em Java!

    Responda

    Kico (Henrique Lobo Weissmann) Reply:

    Delphi é epic. Há momentos em que morro de saudades e quase compro uma das novas versões que, diga-se de passagem, são brutais.

    E que interessante saber que você ta usando o miocc! Tá gostando?

    Responda

    Éderson Cássio Reply:

    Sim, com a criação daquele parser de anotações ele atendeu 100% a minha necessidade. Não é 100% certeza, mas cogito a hipótese de manter ele mesmo, e não trocar pelo Spring na hora de colocar em produção. Aliás, quem vai pra produçao ainda esta semana é o Sisteminha em D7!

    Responda

    Kico (Henrique Lobo Weissmann) Reply:

    Puxa, que bacana! Recentemente movi o código fonte dele para o GitHub (https://github.com/loboweissmann/miocc) e, em um futuro bem próximo, pretendo retomar o desenvolvimento deste projeto. Tenho visto muita gente usando de lá pra cá.

    E que bom vermos o Delphi ainda mandando ver hein? Como te disse, há momentos em que minha mão coça para comprar o XE2 que agora gera até pra mobile! :)

    Responda

    Éderson Cássio Reply:

    É sério, eu fico triste de verdade de ver que a Borland perdeu a mão com ele. A Embarcadero até que está fazendo um excelente trabalho, porém ele já perdeu mercado e virou produto da “zelite” pelo preço proibitivo. Mas se vc instalar uma versão antiga e acoplar nela um monte de componentes (ZEOS, UIB, Jedi VCL e etc.), vc terá um conjunto muito completo para Desktop (não Mobile, infelizmente).

    Os componentes de acesso a dados do Delphi (e os de terceiros que seguem o padrão), embora sejam feitos de classes, requerem uma abordagem procedural para a criação de CRUD’s. Porém, não deixam de ser imbatíveis; nunca vi nenhuma ferramenta de criação de telas de cadastro tão ágil (e isto desde o 1.0 de 1996!!). O problema é saber desenvolver e usar a ferramenta/paradigma certo para o problema certo, e eu acho que uma abordagem Orientada a Objetos me beneficia de verdade somente nos pontos críticos, onde há um pesado encadeamento de regras de negócio.

    Responda

    Kico (Henrique Lobo Weissmann) Reply:

    Opa: então tenho uma boa notícia pra e dar. A última vez que olhei o preço do Delphi, era algo em torno de 1200 a 2000 reais. Com um projeto você paga a licença. :)

    Responda

  4. Concordo em parte com o artigo. Acho que faltou explorar o outro lado, que é a falta de conhecimento e profundidade em OO por parte dos programadores. Isso leva a um mal emprego do mesmo.

    Já trabalho com Java a pelo menos 7 anos e vejo a grande carência de conhecimento dos programadores em relação a isso e principalmente a padrões de projeto. E aí vê-se implementações bizarras de coisas usando teoricamente OO. Aliado a isso as consultorias diminuem cada vez mais os prazos, sendo assim o programador acaba fazendo códigos totalmente procedurais, difíceis de testar, manter, estender e reutilizar. E nisso as empresas perdem tempo e dinheiro, visto que 80% de vida de um software é manutenção.

    O que acho é que em softwares corporartivos, a maioria das vezes OO é a melhor opção. Claro que podemos ter casos onde precisamos de extrema performance (cada milesegundo conta) e aí nesse caso sou a favor de construir a funcionalidade de maneira procedural. Podemos ainda ter cenários onde podemos trabalhar de maneira funcional ou modular, mas isso depende também do contexto. Um bom analista / arquiteto deve sempre analisar os requisitos funcionais e não funcionais dentro de um contexto e com base nisso determinar qual a melhor forma de implementar isso. Esse tipo de profissional acho que hoje está em falta no mercado.

    Responda

  5. Oi Kico,

    Tenho que tirar o chapeu para vc, o unico que vi até agora questionar esta dominação, fora os questionamentos das startups e fábricas de software… concordo plenamente.

    Por gostar muito, passei a vida programando, comecei com basic num cp200, assembly msx, 8088, pascal, c, dbase3, clipper e aí tive meu Primeiro Trauma, a CA desistiu do Clipper for Windows…(Visual Objects). Aí passei pro Delphi 1,3,5,6… Segundo Trauma “putz, o tempo passa e todas as linguagens que adoto, por mais que estejam bombando no mercado, um dia acabam ficando obsoletas… e eu tenho que continuar estudando a vida toda, fugindo da obsolescência. :-(
    Aí depois de velho fui pra facul, obrigado a estudar java, linux, uml, padrões e trabalhar com OO…
    Terceiro Trauma: como é, cada classe tem que ficar num arquivo diferente ? Tenho que digitar uma porrada de gets e sets ? fábrica de objeto ? tenho que fazer 5 códigos, um pra cada camada ?, não tem uma IDE igual ao Delphi, com os componentes todos prontinhos e cheio de libs bonitinhas ? tenho que caçar plugins pra tudo ?

    Aí apareceu o Grails na minha vida pra salvar meu TCC… e você com seus maravilhosos artigos pra encurtar o caminho, salvou um véio que tem preguiça de ler em ingles. Confesso que já estava desistindo do Java e teria partindo para HTML5 e javascript em Node.JS se não tivesse conhecido o Groovy and Grails e você. :-)

    Bom caro Kico pra mim, independente de arquitetura, paradigma ou modelo, tudo no final é procedural, afinal o conteúdo do método ainda é executado linha a linha e tudo no fim é reduzido num assembly executado proceduralmente… adotar OO para tudo é escrever um milhao de linhas de codigo desnecessário todas as vezes.
    Acho que o problema começa na Engenharia de Sistema, pra fazer a documentação toda, como manda o figurino, o Analista vira um montador de documentação e usa e abusa de UML e UML sem classes, é a primeira vez que estou imaginando como seria… .. .. há, vira fluxograma. :-)

    Responda

    Kico (Henrique Lobo Weissmann) Reply:

    Nossa Everton, obrigado!
    Também comecei com o msx :)

    Responda

  6. Problema do Delphi foi que não conseguiu espaço no mercado Web, .NET matou ele e a OOP dominou de vez a cabeça de todos.

    Responda

  7. bom, concordo, pois ultimamente fiz um site que gerenciasse as vendas de uma loja, fiz tanto em OO ultilizando php, como também no modo tradicional, e o que percebi foi a velocidade do modo tradicional, 3 vezes mais rápido do que OO em php, sei que muitos vão concordar comigo ae

    Responda

    anonimo Reply:

    “carlo dutra”, não sabia sobre a velocidade, bom saber isso, mas parabéns por não usar OO com PHP, pois acho coisa de purista, PHP não nasceu para isso! O diferencial do PHP é ser simples para sites de conteúdo, onde você faz o SQL e cospe o HTML baseado no resultset, sem complexidade desnecessária. Para casos complexos que realmente seja melhor um sistema orientado a objetos, outras tecnologias como Java e .NET, se encaixam melhor.

    NodeJS vai mudar essa história que “tudo hoje é OO”.

    Responda

Leave a Reply

Your email address will not be published. Required fields are marked *