{"id":1324,"date":"2013-03-16T19:34:54","date_gmt":"2013-03-16T22:34:54","guid":{"rendered":"https:\/\/devkico.itexto.com.br\/?p=1324"},"modified":"2013-03-17T12:53:42","modified_gmt":"2013-03-17T15:53:42","slug":"corpo-estranho-questionando-a-orientacao-a-objetos","status":"publish","type":"post","link":"https:\/\/devkico.itexto.com.br\/?p=1324","title":{"rendered":"Corpo estranho: questionando a orienta\u00e7\u00e3o a objetos"},"content":{"rendered":"

\"\"<\/a>Rar\u00edssimas vezes me deparo com uma equipe questionando se deve ou n\u00e3o adotar orienta\u00e7\u00e3o a objetos em seus novos projetos. Dado que sabemos n\u00e3o existir bala de prata em software este \u00e9 o tipo de comportamento que levanta minhas antenas para a possibilidade de sermos v\u00edtimas de determinismo lingu\u00edstico<\/a>. Ser\u00e1?<\/p>\n

No mundo dos bancos de dados talvez o evento mais importante das \u00faltimas tr\u00eas d\u00e9cadas tenha sido a populariza\u00e7\u00e3o das bases de dados NoSQL, que trouxeram \u00e0 tona o questionamento a respeito do escopo em que os bancos de dados relacionais deveriam ser aplicados. At\u00e9 ent\u00e3o a cren\u00e7a de que o modelo relacional deveria ser aplicado a qualquer situa\u00e7\u00e3o imperava. E com isto solu\u00e7\u00f5es que poderiam ser implementadas com facilidade em outros modelos eram executadas a duras penas em um formato que n\u00e3o lhes servia. Me pergunto portanto o seguinte: ser\u00e1 que esta nossa f\u00e9 cega na orienta\u00e7\u00e3o a objetos n\u00e3o estaria nos causando o mesmo tipo de problema? Ser\u00e1 que n\u00e3o deviamos criar um movimento NoOOP (Not Only por favor)?<\/strong><\/p>\n

Temo que a orienta\u00e7\u00e3o a objetos tenha nos cegado para as outras op\u00e7\u00f5es. Prova disto \u00e9 que muitas vezes quem levanta questionamentos contra o paradigma (como estou fazendo agora) \u00e9 automaticamente rotulado de retr\u00f3grado, ing\u00eanuo, etc. Sendo assim, antes de continuar, gostaria de pedir ao leitor que evite a postura do mal artista.<\/p>\n

S\u00edndrome do mau artista<\/h3>\n
\"\"<\/a>
Sim, eu vou criticar suas pinturas ruins. :)<\/figcaption><\/figure>\n

Sou a ovelha negra de uma fam\u00edlia composta massivamente por pintores e escultores. Neste meio \u00e9 muito comum a postura do mal artista. \u00c9 f\u00e1cil detect\u00e1-la: \u00e9 aquele sujeito que tem uma obra completamente herm\u00e9tica (e portanto ruim, visto que n\u00e3o consegue comunicar nada) e que rotula todos os que a questionam de insens\u00edveis, incultos, ignorantes, etc.<\/p>\n

O mesmo vejo acontecer na nossa \u00e1rea de TI. Ali\u00e1s, j\u00e1 at\u00e9 escrevi sobre isto ao abordar a quest\u00e3o dos fan boys<\/a>. 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\u00e3o acredito que o problema esteja na OOP em si, mas sim no uso for\u00e7ado desta.<\/p>\n

Jogando o ouro fora<\/h3>\n
\"\"<\/a>
Foto de um projeto OO ultra high tech que substituiu um sistema legado que funcionava. N\u00e3o \u00e9 lind\u00e3o?<\/figcaption><\/figure>\n

Em diversas consultorias que dou topo com a mesma situa\u00e7\u00e3o: uma equipe composta por bons programadores que devem ser reciclados (odeio<\/strong> quando usam este termo) para uma tecnologia mais moderna<\/em>. Normalmente v\u00eam na forma de alguma linguagem orientada a objetos. E ent\u00e3o come\u00e7am aquele processo nojento de substituir software legado que funciona por software escrito do zero na linguagem OOx (Joel Spolsky tem um texto maravilhoso<\/a> sobre isto) que pode terminar na demiss\u00e3o de um ou outro funcion\u00e1rio e que SEMPRE mina a auto estima dos desenvolvedores mais antigos.<\/p>\n

Nestes momentos eu sempre me pergunto o seguinte: se voc\u00ea j\u00e1 tem algo que funciona bem por anos, que tipo de v\u00edrus \u00e9 este que invade a mente dos gestores que os leva a jogar fora a prata da casa? Ei, eu sei: hype<\/a>. Eu fico impressionado como nestes casos uma equipe composta por profissionais talentosos \u00e9 trocada por outra que, na maior parte das vezes, ser\u00e1 no m\u00e1ximo med\u00edocre. Os novatos podem at\u00e9 mesmo ter uma vis\u00e3o t\u00e9cnica mais avan\u00e7ada sobre a nova tecnologia imposta (normalmente tem), mas o que realmente importa, que \u00e9 o conhecimento por tr\u00e1s dos problemas que precisam ser resolvidos, n\u00e3o.<\/p>\n

Ent\u00e3o pergunto: se sua equipe t\u00e1 trabalhando BEM com uma linguagem procedural como PL\/SQL ou alguma outra de neg\u00f3cio, realmente<\/strong> \u00e9 necess\u00e1rio trocar a tecnologia e, com isto, transformar sua equipe experiente em um bando de estagi\u00e1rios? Este \u00e9 meu primeiro questionamento. E esta experi\u00eancia que tenho \u00e9 a base pro resto deste post.<\/p>\n

Qual complexidade importa? A quest\u00e3o dos verbos<\/h3>\n
\"\"<\/a>
Yeap, solu\u00e7\u00f5es n\u00e3o OO tamb\u00e9m podem!<\/figcaption><\/figure>\n

No desenvolvimento de software h\u00e1 duas complexidades. A primeira \u00e9 inerente ao problema que precisamos resolver. N\u00e3o h\u00e1 muito o que possamos fazer a n\u00e3o ser estudar ao m\u00e1ximo sua natureza. A segunda diz respeito \u00e0 dificuldade na implementa\u00e7\u00e3o da solu\u00e7\u00e3o, que normalmente piora de acordo com nossas escolhas mal feitas.<\/p>\n

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<\/strong> precisarem se preocupar com coisas que n\u00f3s, que trabalhamos com OO lidamos o tempo inteiro, como por exemplo padr\u00f5es de projeto, encapsulamento, etc. Os caras se dedicam apenas \u00e0 implementa\u00e7\u00e3o da solu\u00e7\u00e3o do problema, e isto n\u00e3o quer dizer que o software gerado \u00e9 ruim. (voc\u00eas sabem que existe sistema feito sem orienta\u00e7\u00e3o a objetos bom por a\u00ed n\u00e9? :) )<\/p>\n

Observando o c\u00f3digo fonte fica claro que ele expressa BEM o modo de pensar do programador: foco no verbo. Yeap, quando planejamos uma a\u00e7\u00e3o, n\u00e3o pensamos nas entidades que precisam ser implementadas, mas sim nas a\u00e7\u00f5es<\/strong> que precisamos tomar. Na abordagem puramente OO v\u00eamos o pensamento contr\u00e1rio: o sujeito primeiro projeta as suas classes e DEPOIS o que elas fazem (Steve Yegge tem um texto excelente<\/a> sobre isto). O modo de pensar OO primeiro v\u00ea os substantivos: s\u00f3 depois os verbos. Ser\u00e1 que isto \u00e9 uma coisa boa? Ser\u00e1 que n\u00e3o est\u00e1 a nos levar para uma solu\u00e7\u00e3o mais complexa do que precisamos?<\/p>\n

Algumas das perguntas que escuto em consultorias em um primeiro momento podem parecer tolas em sua superf\u00edcie, mas exp\u00f5em muito bem o mau uso da OO. Seguem algumas:<\/p>\n