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:
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!
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! :)
Concordo plenamente! Um amigo e eu fazemos vários stacks de linguagens quando vamos implementar um novo projeto. Uma linguagem ou tecnologia nova pode entrar em algum stack para avaliação por um simples “quero aprender isso”, como nós já sabemos bem uma liguagem de mercado, então logo no início conseguimos identificar a dificuldade das coisas e prosseguir ou não.
A liberade é a melhor escolha.
Entra mais coisas mais questões, porque fazer um sistema web stateful com sessões refletindo tudo que o usuário tem e faz? Porque não usar o que já esta implementado como SSL, http basic authentication, indexeddb e uma aplicação web stateless?
Eu colocaria muito mais lenha na fogueira que você criou pra ver se a ficha das pessoas caem e parem de só pensar de uma forma!
Outra coisa é, não programamos ( estou generalizando pois 100% dos projetos que passei ) OO de verdade? Estamos programando procedural/estruturado em linguagens Orientadas a Objeto. É fato e é difícil fazer as pessoas perderem o medo de colocar coisas novas como uma classe anônima ou usar um try-resource ou um foreach do java nos códigos novos…
Abraços
O “não programar OO de verdade” é o maior problema. Um vez projetando um domínio de sistema em OO e alcançando os benefícios reais, qualquer questionamento relacionado à “um objeto poderia ser uma estrutura de dados” se desfaz. Se for necessária a comunicação remota entre dois sistemas (camada física), entra o padrão DTO, que nada mais é que um “struct” para linguagens orientadas a objeto – que infelizmente muitos utilizam dentro das camadas lógicas do software.
O maior problema na nossa área é falta de contexto. Existem vários patterns (padrões) e anti-patterns e todos eles sem contexto. Então se cria a ditadura dos “padrões de mercado” que desconsidera o principal: contexto. Por exemplo, JPA/Hibernate é considerado um “padrão de mercado”, contudo para processamento de altíssimo volume de dados (em lote) com janela limitada, usar mapeamento objeto-relacional se torna de fato um anti-pattern. Tudo depende do contexto. Por outro lado, se a janela de execução não for um problema, dá pra usar mapeamento objeto-relacional com entidade desconectada ou gerenciando o flush de dados. Tudo depende do contexto.
Outro problema é o famoso “a tecnologia/paradigma/linguagem que uso é a melhor que existe”. Considerando que existem vários contextos e várias tecnologias, pra cada contexto pode haver uma solução diferente.
Algo que pode chegar próximo disso (multi-contexto) são exatamente as linguagens multi-paradigma como Groovy e Scala e suas frameworks.
Sou fã de Groovy por ser OO, funcional e principalmente pelos recursos de uma linguagem dinâmica como AST e MOP (metaclass). Ou seja, uma ‘ferramenta’ que atende a vários contextos. O multi-paradigma não é só a tendência, é uma realidade do mercado. Mas a educação é primordial.
Eu concordo, e falo isso faz algum tempo tb… não sou exatamente um exímio programador, mas pretender que uma solução qq vai ser sempre a melhor, é sintoma de que se está forçando a barra pra não sair da zona de conforto…
Chutando um pouco o pau da barraca, e usando o kernel do linux como exemplo, daria pra implementar usando outras linguagens? o kernel é basicamente c, e algum assembly, mas ninguém sequer pensa nisso, primordialmente pq TODO o código é legado, e FUNCIONA.
O Dijkstra tem uma frase ótima, na qual ele diz algo como ‘estudantes que iniciaram programando em BASIC estão além da capacidade de regeneração’. :) Bom, Um analista deveria propor a melhor solução, não a mesma solução sempre, e pra isso precisa conhecer essas soluções, para poder reconhecer um possível caso onde é melhor utilizar essa ao invés daquela tecnologia. Hoje não começan com BASIC nas escolas, mas enfiam java, .net e outros pela goela dos estudantes, que saem da faculdade com a nítida impressão de que é isso que existe, o resto é bobagem ter no currículo (ouvi isso na fatec)…
Apenas a título de curiosidade, a Bentley, fabricante do Microstation, resolveu criar uma das versões dete soft compatível com java. Mas era um java dela mesma, que tinha structs e coisas que tais… e, declaradamente, essas incompatibilidades foram introduzidas por questões de performance. É óbvio que isso não deu muito certo, pois tornava qq coisa que vc tivesse incompatível com o programa, a não ser que vc tivesse os fontes – e a premissa básica do java era “compilar uma vez, rodar em qq lugar”, então ninguem usou… Hoje o Microstation é totalmente .net (pra minha infelicidade, pois se tivessem simplesmente implementado um java normal seria muito bom).
Enfim… embora alguns programadores tenham uma relação de quase asco com o c++, é interessante a abordagem de orientação a objetos “não obrigatória” desta linguagem. Isso introduziu TANTAS complexidades que fomentou o aparecimento do java mais tarde, mas… será que um java sem oo obrigatória, mas com as facilidades de programação não teria sido um caminho melhor a seguir? exatamente um java NoOO (ponto pro kico, aliás :)
Abraços!
Eu tenho a suspeita de que por estarmos sendo acidentalmente obrigados pelo mercado a adotar OO em tudo talvez estejamos gerando soluções bem mais complexas do que o necessário.
Não suspeiro, já tenho certeza. Hoje aqui em SP existe muito disso: Vamos utilizar java que é mais fácil encontrar profissional barato. Mas esquecem de “ensinar” java aos profissionais baratos, então se chega um que sabe java OO este consequentemente sabe ruby, groovy, scala e outras OO por osmose, logo é também mais caro e as pseudo-analistas de RH descartam estes caras.
Chamo este comportamento das pseudo de “me engana que eu gosto”, o cara engana que sabe “bem” java e engana que é sênior, pronto a analista já vende ele como solução para o cliente.
Lobo, concordo em parte contigo, acredito que como desevolvedores de soluções, devemos primar pelo pragmatismo em nossas ações, SEMPRE; por conta do prazo e verba cada vez mais apertados, por otimização do nosso tempo (talvez nosso maior ativo) o qual dedicamos a cada tarefa, e por aí fora.
Pensar desta maneira, nos obriga a buscar a solução mais prática e eficiente para cada tipo de problema, mas o paradigma (Procedural, OO, funcional, imperativo ou lógico), apenas sugere um caminho confortavel de solução em um conjunto de possibilidades; ainda mais hoje em dia, quando a maioria das linguagens cobrem mais do que 1 paradigma, e quando não, pelo menos oferecem um workaround que procura satisfazer esta necessidade.
Se comparamos o paradigma de programação a uma via que te leva a um destino, poderíamos caracterizar OO, como uma via longa, ampla e rápida (acredito que por este motivo é o principal paradigma ensinado nas escolas), mas longe de ser o caminho que te leva a todos os lugares.
Na minha opinião, o equívoco seria limitar nosso escopo de conhecimento a um único paradigma, uma única linguagem ou tecnologia. Se só conhecemos OO, tentaremos usa-la para resolver todos os problemas que aparecerem: Quanto você só tem um martelo, todo problema que aparece você pensa que é prego. Mas o mesmo ocorreria se fossemos excessivamente funcional, procedural, ou whatever…
Defender noOOp, criaria a necessidade de defender também: noFp, noPp, e por aí fora… Acho que, o que realmente devemos estimular é: Permita-se pensar de maneira diferente. Conheça outros conceitos, paradigmas, linguagens, frameworks…, e tente imaginar como seus requisitos de software seriam resolvidos por estes diferentes prismas.
Abraços,
Keep going…
Cesar Barbosa
Oi Cesar, eu concordo com quase tudo o que você diz.
Mas sabe: acho que tem de surgir um noFp, noPp, no* sempre que um paradigma ofuscar todos os outros.
(claro, nunca no como NOT, mas sempre como Not Only)
Sabe: é questão de ser pragmático mesmo. A partir do momento em que me pego pensando em apenas um paradigma – que é o que ocorre hoje com OO – fica nítido pra mim que minha vida talvez pudesse ser mais fácil pensando fora da caixa, saca?
Yeah, I see, “Not only” is always the most suitable measure, “not” would be too radical…
Parabéns pelo site.
Valeu!
Excelente colocação César!
Obrigado Amigo,
um grande abraço!
Post interessantíssimo. Hoje em dia gasto a maior parte do meu tempo de pesquisa aprofundando em Haskell, com o objetivo de, depois, pegar Erlang (não existe muita lógica de progressão nisso, mas ok).
Comentei isso com um colega e ele perguntou das linguagens e tal, disse que eram funcionais, não tem variáveis etc., queria aprender MapReduce e alguns algoritmos novos que caem melhor em linguagens funcionais, e então ele me disse “mas essas coisas só podem ser feitas nessas linguagens?”
Engraçado que eu sou um programador Python, uma linguagem que te dá liberdade pra escrever tanto código procedural quanto OO, e recentemente eu critiquei um código que era 100% procedural, perguntando a mim mesmo se uma classe não seria mais adequada. O módulo em questão tinha um bom bocado de variáveis globais, mas agora lendo esse artigo…
Este meu questionamento surgiu de uma situação similar à sua Lucas. Foi um momento do tipo: “pô! se eu não quiser usar OO, o que eu uso pra isto hein?”
E aí percebi que OO tava me cegando.
Tem outro problema também: o sujeito se convence, “OO pode não ser o melhor pra este trabalho”, e então procura no Google, e aí é que a decepção começa… o material oficial de Haskell, por exemplo, não é nada intuitivo, pelo contrário. Faz um tempo que ando tentando “pegar a coisa” de continuations em Racket, mas a coisa simplesmente não flui.
Outro detalhe, na programação puramente funcional, ao menos, é a ausência de variáveis. Eu larguei a linguagem, chamando-a de inútil, simplesmente por não poder fazer isso. Quando a forma de pensar, finalmente, muda, as coisas começam a progredir.
Neste caso você tá tomado por determinismo linguístico.
Seu modo de pensar foi amputado pelo vício que a OO exerceu sobre você. Rola muito isto.
Eu vejo muito ocorrer, por exemplo, em gente que começa no procedural e vai pra orientação a objetos.
Não se desenvolve um sistema comercial com Haskell. Um bom exemplo de falta de contexto…
Fazer um script para decodificar genoma através de cálculos matemáticos (onde o Haskell e qualquer linguagem funcional detona) é bem diferente que um sistema que controla um processo cheio de regras de negócio. Ou então um processamento de bilhetagem de telecomunicação ou faturamento de cartão de crédito.
Enfim, nossa área está cheia de contextos e nós simplesmente lemos o que o mercado fala mas ignoramos o contexto para tomada de decisão.
Em tempo, é válido aprender Haskell, Erlang, etc. Eu mesmo aprendi Smalltalk pra entender o que era OO de verdade. Inclusive há quem recomende aprender uma linguagem nova por ano. Mas dai pra aplicar a linguagem em produção ou dentro de uma equipe é necessário muito mais que um estudo individual. Por isso recomendo linguagens multi-paradigma como Groovy e Scala. É muito mais fácil pra uma equipe se adaptar. Você consegue inovar simplesmente evoluindo e não revolucionando e assumindo altos riscos.
Abraço!
Será que não se constrói porque não é possível (ou não fica bom) ou porque “Seu modo de pensar foi amputado pelo vício que a (OO|estilo imperativo de programar) exerceu sobre você”? O que realmente impede de serem construídos sistemas comerciais com Haskell, afinal?
De toda forma, acredito que não seja este o ponto do post, e nem do meu comentário também, como explicarei depois. O ponto do post é justamente detectar situações onde outros paradigmas de programação são mais eficazes para se resolver um problema, não está diretamente relacionado à linguagens e plataformas. E se eu trocasse Haskell em “Não se desenvolve um sistema comercial em Haskell” por um variante do LISP ou ainda Erlang, será que o resultado é o mesmo?
Sobre “Ou então um processamento de bilhetagem de telecomunicação ou faturamento de cartão de crédito.”, o que dizer, então, dos vários sistemas de telecomunicação escritos em Erlang, uma linguagem puramente funcional (corrijam-me se eu estiver errado)?
Por fim, talvez eu tenha sido pouco claro no meu post original. As minhas motivações em aprender Haskell e Erlang não são para, necessariamente, usá-las diretamente no dia-a-dia, e sim para aprender os conceitos, paradigmas, numa linguagem que incentive isso da melhor forma possível.
Eu concordo demais com você Lucas.
Sabe Lucas, eu acredito demais que nós estamos usando o paradigma errado o tempo inteiro. Nâo que OO seja ruim, como já disse diversas vezes, não é o ponto.
O grande ponto é que ao colocarmos OO em TUDO (e a gente faz isto o tempo inteiro), a gente simplesmente foge de soluções mais simples.
Eu me lembro, por exemplo, do caso da Viaweb, que depois virou a Yahoo! Stores. Foi o primeiro sistema de eCommerce que possibilitava ao comerciante criar a loja online, montar os cruds e tudo mais. Muita gente poderia dizer que a abordagem inicial seria usar orientação a objetos, certo? No entanto, não foi: foi funcional. Foi usado o Lisp, e é um caso famoso de acerto total na escolha do paradigma, porque de acordo com os relatos do criador do site (Paul Graham), a produtividade e qualidade final do trabalho foi monstruosa.
Em um ambiente cegado pela OO, teríamos visto isto sendo implementado puramente com classes, objetos e acabaria sendo gerado algo provavelmente mais complexo do que o necessário. Acho este um exemplo excelente (que eu devia ter incluído no post mas esqueci) de como uma mente aberta a outras abordagens nos ajuda.
E com relação à questão do “ferramenta certa pro local apropriado”, tá mais que batido né? É chover no molhado, não vou repetir isto aqui.
Uma das frases que mais gosto de usar é: “Dá pra fazer tudo em qualquer coisa, mas qual o tempo, investimento e profissional?”. Isso define tudo na nossa área – ou pelo menos deveria.
Enquanto ficarmos nos perguntando ‘será que…?’ ao invés de praticar e chegar numa conclusão clara, nunca chegaremos no nosso objetivo: entregar resultado rápido para o negócio fim.
Nós sempre iremos ver notícias de pessoas desenvolvendo sistemas com qualquer linguagem. Agora tudo deve ser considerado sob o âmbito de mercado. Em comparação com outra plataforma comercial, como PHP, .NET ou Java não representa nem ‘0,001% do mercado’.
Se a tomada de decisão da arquitetura de um sistema não leva em conta várias fatores como ‘talentos no mercado’, o decisor (aquele que cumpre o papel de arquiteto do sistema, seja oficialmente ou não) simplesmente está assumindo um risco enorme. E risco é aquilo que devemos sempre reduzir para garantir o sucesso de um projeto. Não há como programar um sistema comercial sozinho com o time-to-market exigido hoje em dia e desconsiderando fatores latentes como o altíssimo turnover (troca de profissionais) em nossa área.
Vou contar um pouco da minha experiência…
Em todos estes anos eu só conheci 1 pessoa que desenvolveu uma aplicação Web em linguagem funcional (LISP). E o que ele disse: me arrependi, pois por mais que tenha ficado maravilhoso (do ponto de vista LISP), só ficou maravilhoso pra mim pois ‘ninguém’ conhece LISP, ainda menos na lib que eu usei.
Também trabalhei com o guru do Perl+CPAN no Brasil há exatos 12 anos atrás que fazia um sistema Web com um pé nas costas muito mais rápido do que a gente conseguia na época com ASP e PHP.
O resultado do guru Perl era rápido simplesmente pq ele era fora da curva. Sistemas gigantes com poucas linhas de código. Maravilhoso do ponto de vista estritamente técnico. Mas… ninguém conseguia manter um sistema que ela lotado de one-liners e expressões regulares. Ninguém mais conseguia mexer no código. Se o guru não estava disponível, o mundo acabava.
Por isso reitero minha simpatia pelo Groovy, Scala e todas as linguagens multi-paradigma. Digo novamente, e isto foi também dito por outros: isso é algo que não está mais em discussão ou pesquisa, é uma realidade – há anos.
O Groovy em especial pq quebra o paradoxo: ‘adota’ toda a comunidade Java com uma curva de aprendizado mínima, aproveitando todo o conhecimento adquirido (conhecimento é tempo e tempo é dinheiro) e com todos recursos modernos como metaclass, closures e paralelismo pra citar algumas. Assim conseguimos ser pragmáticos (decisão rápida e focada no resultado) com muito menos riscos.
Abs!
resumindo: maria vai com as outras.
Quando falta maturidade pra debater um assunto, o que sobra é isso ai…
cara: falta paciencia
seus comentarios sao gigantescos, extremamente prolixos e, fica a dica. Junto vom a maturidade vêm também a concisão. Alho que fica longe dos seus comentarios.
Alias, engracado vocr falar de maturidade. Adolescentes é qye normalmente são verborragicos assim.
Fico satisfeito pois agora tudo está muito claro.
Paciência num debate é fundamental.
Apesar de considerar a mensagem final de seu comentário correta e positiva, vamos por partes:
“Uma das frases que mais gosto de usar é: “Dá pra fazer tudo em qualquer coisa, mas qual o tempo, investimento e profissional?” ”
A frase que introduz o parágrafo seguinte – este sim, interessante – conduz a uma conclusão conveniente para a OO, que é a melhor que satisfaz estes três quesitos. O que é verdade, no geral, mas apenas noto que “tempo” é relativo à experiência do profissional ou profissionais. Ainda assim, reforço: o artigo *não diz* sobre abandonar a OO ou “vamos usar linguagens funcionais, YAY”, e sim de usar o paradigma mais adequado para cada caso, e nessa situação é mais que óbvio que a OO, simples e pura, não basta. Mesmo no “domínio da aplicação”, como você disse em outro post, há trechos onde uma abordagem funcional é mais conveniente. Há inclusive trechos onde funções ordinárias são o suficiente!
“Enquanto ficarmos nos perguntando ’será que…?’ ao invés de praticar e chegar numa conclusão clara, nunca chegaremos no nosso objetivo: entregar resultado rápido para o negócio fim.”
Parágrafo interessante. Parece aquele cara que se levanta no meio de uma discussão e diz “gente, vamos parar de falar e ir ao trabalho”. Parece idiota, mas nem sempre é válido. E o que impede nos perguntarmos “será que…?” e ainda praticar e procurar conclusões? Por fim, a indireta com “entregar resultado rápido para o negócio fim”… considerando seus posts anteriores, presumo que esteja falando da OO como ferramenta para entregar resultado rápido… não vou mais comentar este trecho, já respondi acima sobre a velocidade depender do profissional ou equipe, e ainda há a ferramenta adequada pra cada trabalho…
Antes de continuar, deixe-me concordar contigo em uma coisa: sim, também acho pouco inteligente utilizar uma linguagem esotérica para desenvolver um sistema (geralmente). Mas veja (eu até revisei o meu post anterior), eu *não estou* levantando a bandeira para linguagens assim, ou mesmo Haskell, que é a que estudo no momento. Falar de paradigma é uma coisa, falar estritamente de linguagem é outra, os argumentos mudam.
Mais ainda, considero o exemplo sistema em Perl que descreveu bastante infeliz. One-liners quase sempre não são uma boa prática para grandes sistemas, e regex altamente complicadas também não. Eu mesmo, apesar de bem novo, já vi alguns códigos Perl bastante legíveis. De novo, aqui, estamos desviando e entrando em outro tema…
Conheço a razão de existir da OO e entendo em grande parte parte o seu valor, apesar de continuar criticando (no sentido de questionar) algumas de suas features. Veja bem, eu *faço uso* da OO todos os dias.
Por fim, eu também concordo com você: tenho grande preferência por linguagens multi-paradigma. Discordaria sobre o Groovy “quebrar” um paradoxo, já que já haviam outras linguagens antes dela que tinham a mesma ideia.
No mais, acredito que não haja mais nada a ser dito. Se fui mal-interpretado por você anteriormente, espero que essa resposta seja mais esclarecedora. Reiterando: eu *não* estou incentivando o uso de linguagens esotéricas no desenvolvimento de software, estava concordando com o artigo do Kiko e divagando a respeito.
Está tudo bem claro agora.
Sobre Groovy, observe que eu citei o aproveitamento do conhecimento em Java. Não conheço outra linguagem que evoluiu a sintaxe Java ao invés de “revolucionar” com uma nova sintaxe na JVM. Esta vantagem quebra o paradoxo: manter a eqipe comum linguagem defasada ou treinar todo mundo numa nova linguagem.
Sobre “processamento de bilhetagem de telecomunicação ou faturamento de cartão de crédito” é exatamente o que foi colocado: não se usa OO. Ainda existe muito COBOL rodando este tipo de workload e quando atualizado são Stored Procedures diratemente no banco de dados para gerenciar de forma eficiente a massa de dados.
Utilizar abordagem funcional, caso a plataforma tenha um desempenho aceitável é totalmente adequada.
Com este questionamento eu acredito que deve ter entendido que estou defendendo o uso de OO em todos os contextos, quando na verdade é totalmente o contrário. OO tem seu contexto de uso, e no seu contexto que é o Domínio, é algo amadurecido e comprovado. Se não conseguiu perceber isso ainda, sugiro ler novamente o que foi escrito com paciência.
Abs!
Puxa vida, li este post antes da resposta acima, que deu em outra thread. Você parece ter “jogado” o desentendimento da nossa conversa nas minhas costas. Eu, por outro lado, acredito que tenha me interpretado errado desde o início, e prosseguido dessa maneira. Estamos em um impasse, afinal.
De toda maneira, achei seus comentários bacanas e foi bom discutir contigo, apesar de termos discordado bastante…. já deixei um comentário bem grande em outra thread, se quiser podemos continuar por lá. A menos, é claro, que continue me interpretando errado.
Lucas, vc só não tinha sido claro, algo que vc mesmo disse e só tenho que lhe agradecer pela grandeza no debate. Agora está tudo bem esclarecido!
@Lucas
“….e recentemente eu critiquei um código que era 100% procedural, perguntando a mim mesmo se uma classe não seria mais adequada. O módulo em questão tinha um bom bocado de variáveis globais, mas agora lendo esse artigo…”
Este é o problema… agora até variável global tá legalizada. Olha o que você foi arrumar Kico! rsrsrsrs
Brincadeiras a parte, pelo bem da comunidade de software e da sanidade de quem vai dar manutenção do seu código… continue criticando esta prática, Lucas!
As variáveis globais em sistemas de informação são uma praga que pagamos muito caro. Se for pra fazer scripts (um arquivo), como bash por exemplo e até groovy, não tem problema algum. Até porque o número de linhas é pequeno. Nada muito complexo além da sintaxe. Agora se o arquivo crescer, vai haver necessidade de encher de GOTOs… tssss. Saiba que os problemas não só aparecem, mas multiplicam. A legibilidade do código vai pro espaço e só vai entender o pai da criança, rs.
Segue um exemplo de como isso é “penoso” em JavaScript hoje em dia.
http://alextercete.wordpress.com/2010/01/15/o-problema-com-as-variaveis-globais-no-javascript/
Veja uma situação onde isso acontece: numa equipe sem liderança técnica e revisão em pares, várias pessoas criam arquivos.js e vão adicionando no template global. É uma bomba relógio.
Como resolver isso no JS? De forma muito simples, encapsular a variável em um objeto criado com JSON (extremamente simples como verá abaixo). Isto é chamado de ‘namespacing’, similar a pacotes Java e evita o conflito de variáveis.
http://javascriptweblog.wordpress.com/2010/12/07/namespacing-in-javascript/
Abraço!
Eu não passei a aceitar variável global só por conta desse artigo, inclusive este foi outro ponto em que fui pouco claro. O que quis dizer é que, ao ver o código, questionei se aquelas funções todas alterando variáveis globais não ficariam melhores se escritas como uma classe. Ainda assim há outra refatoração possível, que é eliminar o uso de variáveis globais e transitar o estado através das chamadas de funções, o que é, inclusive, bastante próximo do jeito funcional de se programar.
E sabe uma outra coisa que eu fico pensando Lucas?
Este papo de “o mercado reagiu criando linguagens híbridas que são OO e também implementam os paradigmas X, Y, Z”, será que o fato de ter OO como paradigma já não seria um indício de que estamos incluindo OO pra tudo?
Dias desses estava perguntando a um colega, que programa em Clojure, se era possível escrever classes nessa linguagem. Ele respondeu “É preciso?”, e eu não tinha a resposta na hora.
Este é o tipo de momento lindo que joga nossos preconceitos todos pela janela.
Eu to passando por diversos assim recentemente. Foi isto que me incentivou a escrever este post. Sabe aquele momento em que você olha pra sua frente e percebe que tá jogando fora todo um espectro de possibilidades gigantesco? To nele agora.
É a hora que a ‘revolução’ joga fora tudo o que foi conquistado, por capricho de alguém que viu o problema em uma abordagem, lutou por isso com afinco e no final das contas viu que na verdade era só uma questão de contexto.
E eis o pêndulo da área de TI. Questiona algo e o elimina. Depois que o mercado entende realmente o contexto daquilo que foi eliminado, ele volta com uma força maior que a primeira – pq está no contexto correto.
Poderia dar vários exemplos, um deles é computação distribuída (SOA) que veio como CORBA e EJB e voltou como SOAP e REST. Outro seria o XML, um mero protocolo de comunicação que era considerado até a panacéia da interoperabilidade, sendo até mesmo meio de armazenamento, antes da desilusão inicial do mercado. Agora a abordagem funcional que era confundida com procedural e foi eliminada e agora existem as linguagens híbridas.
Me questiono até quando Hype Cycle do Gartner será uma verdade latente na nossa área: https://www.google.com/#hl=pt&q=hype+cycle
A história da nossa área mostra que se escolhermos a “evolução” ao invés da “revolução” em todo ciclo de mercado, não só a economia agradece, mas nossa saúde tb. :-D
Abs!
Há dois caminhos a seguir. O arriscado que é ser pastor e o cômodo e mediocre que é ser ovelha.
Opto pelo primeiro. Questiono mesmo, e vou continuar questionando, e principalmente experimentando cada vez mais e, o que é melhor, me divertindo ao tocar nervos. :-)
Está tudo bem claro agora.
O bom debate é este: ambas as partes se entendem mesmo que tenham pontos de vista diferentes. E principalmente sem acusações, somente argumentos e paciência para compreensão.
Sobre Groovy, observe que eu citei o aproveitamento do conhecimento em Java. Não conheço outra linguagem que evoluiu a sintaxe Java ao invés de “revolucionar” com uma nova sintaxe na JVM. Esta vantagem quebra o paradoxo: manter a eqipe comum linguagem defasada ou treinar todo mundo numa nova linguagem.
Kico, é 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.
O maior problema da programação procedural é que não contava com um método de desenho equivalente (só existia o método Relacional). Hoje o único método de desenho com o qual contamos é OO. Não existe alternativa ainda.
Coisa diferente é a linguagem que usamos. Parece natural usar uma linguagem OO para implantar um desenho OO, apesar de que isso não é obrigação. De fato, muita gente opina, incluido Uncle Bob por exemplo, que as linguagems funcionais (Clojure, Scala, F#, Erlang, etc.) implantam muito melhor um desenho OO.
Os linguagems que se chamam OO na realidade não são OO de verdade. A pesar de que hoje já estão aparecendo muito melhores: com estruturas como você reclama no teu post ;-), com closures, monads e outras coisas muito úteis.
Convido a ler meu post: http://www.rodrigosalinas.cl/una-nueva-arquitectura/. Por favor perdoa meu português ruim e continua sempre escrevendo.
Oi Rodrigo, obrigado.
Muito interessante os seus pontos. Na realidade, eu não estou atacando a orientação a objetos em si nem uma linguagem ou outra. De fato: há linguagens orientadas a objetos que possuem alguns dos recursos que sinto falta em java: como as estruturas, que aparecem no C#, por exemplo.
A grande crítica é o fato de estarmos tão acostumados com o sucesso da orientação a objetos que simplesmente, ao tratarmos de um problema, pernsarmos de forma imediatamente orientada a objetos, ao invés de tentar outras alternativas, como procedural, funcional, lógica, etc.
Este pra mim que é o grande problema que enfrentamos atualmente. Como acho que já disse em algum comentário, eu tenho a séria desconfiança de que estamos ignorando diversas alternativas que poderiam ser usadas e não são devido a esta nossa limitação mental.
E ei: seu português é excelente!
“É 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.
Acredito que você conclui bem. O problema não é OO, mas sim o seu excesso, ou o seu mau uso.
Já vi situações em que foi imposto o uso de OO a equipes que não a compreendiam tão bem, mas dominavam programação estruturada, e resolveriam o problema muito melhor dessa forma.
Em muitos casos, OO tem vantagens reais e desejáveis, mas somente obtidas se a equipe estiver preparada. Em outros casos, ainda que usando uma linguagem dita Orientada a Objetos, como C#, o cenário a ser implementado se enquadra muito melhor em um paradigma funcional, e pode muito bem ser assim implementado nessa mesma linguagem. Ou isolado em um módulo do mesmo sistema implementado em F#, por exemplo.
Acredito que cabe sempre o bom senso e a experiência dos profissionais responsáveis para avaliar cada situação antes de determinar paradigma e linguagem a serem usados, nunca fazendo escolhas com base apenas em preferências pessoais ou tendências.
Muito boa colocação.
Parabéns pelo texto, boa reflexão.
Sou programador há mais de 23 anos, de um tempo que não existia OO, e nem mouse, e confesso que migrar do modo estrutural para o OO sempre foi meio traumático, no começo (e talvez até hoje) a maioria das classes que crio sejam apenas um aglomerado de métodos para evitar o CTL+C/CTRL+V.
Hoje vejo muita gente que por abusar do OO se tornam programadores preguiçosos, sempre em busca de uma classe/método/app/plugin pronta para resolver um problema que se gastasse um pouquinho de tempo pensando (talvez menos do que procurar a tal classe mágica) resolveria e ainda por cima saberia como aquilo funciona, sem ter apenas a classe mágica que nem faz idéia de como ela funciona realmente.
Mesmo no OO há de se lembrar que os métodos ainda são estruturados, e como você bem citou a questão do verbo e o substantivo, a lógica das ações é muito mais importante do que a linguagem ou o paradigma escolhido.
Este é o custo negativo de qualquer componentização mal feita, em que o componente passa a ser visto como um martelo e o mundo um prego né?
Kico,
Excelente assunto para ser debatido, principalmente educar a comunidade brasileira a respeito do uso das abordagens de projeto e desenvolvimento.
A OOP já foi questionada como solução para qualquer contexto há um bom tempo. Os resultados são as linguagens híbridas como Scala, Groovy, Clojure dentre outras que não são mais o futuro mas sim a realidade. Até mesmo a Spring lançou o Spring Batch que é uma framework exclusiva para tratamento de processamentos em lote, quando se é sabido que para tal tarefa, um mapeador ORM é um overhead para alto volume de transações simultâneas. Contudo esta é só uma (pequena) parte da aplicação, apesar de muito importante em várias ocasiões.
O texto aborda questões interessantes mas certas afirmações se desmancham no decorrer do texto. Um exemplo, é o título “Questionando a Orientação por Objetos”, já que em determinado momento se afirma “Na realidade, eu não acredito que o problema esteja na OOP em si, mas sim no uso forçado desta”. O título ideal na minha opinião seria “Orientação por Objeto não é o único caminho”. Alguém mais concorda?
Questionar a OOP como está no título – e não seu uso – é como ‘jogar o bebê limpo junto com a água suja da banheira’. Os ganhos da OOP no domínio da aplicação (pra onde ela foi concebida e totalmente indicada) são inquestionáveis pra quem realmente conhece como projetar um domínio orientado a objetos. O problema é que a maioria dos colegas ainda nem conhece realmente os benefícios da OOP usando objetos como meras estruturas.
Recomendo a todos que leiam o livro Domain-Driven Design (http://en.wikipedia.org/wiki/Domain-driven_design) de Eric Evans, no qual ele e Martin Fowler discutem lá no final dos anos 90 como o J2EE (EJB 2) era mais procedural do que realmente orientado a objeto, pois eles conseguiam OO *de verdade* em Smalltalk e não conseguiam em Java.
Hoje esta o uso de OOP é uma situação resolvida com Hibernate e já padronizado com JPA no âmbito das entidades de domínio. O problema é que muitos usam mapeamento objeto-relacional e ainda externalizam *todas* as regra de negócio na camada de Serviço (a API da aplicação que é procedural e na maioria das vezes singleton). Assim realmente é fácil questionar se as entidades de domínio não poderiam ser simplesmente estruturas de dados e não objetos. Não está se fazendo uso de objetos!
Este questionamento é recorrente de quem não usufrui dos reais benefícios da OOP, como DRY, separation of concerns, eliminação de IFs, legibilidade, maior manutenibilidade e principalmente *redução da complexidade do domínio da aplicação*. A OOP proporciona um melhor entendimento do negócio programado em código por trabalhar com objetos de domínio que refletem o mundo real.
A produtividade é somente um item a ser levado em consideração na definição de abordagens e tecnologias. Do contrário eu estaria muito feliz programando em ASP e VB6, mas totalmente estressado se pegar um sistema destes pra manter – mesmo que seja programado da melhor forma possível pois não permite atingir certos benefícios da OOP.
Enfim, uma linguagem (ainda mais hoje em dia) não é inerentemente “orientada a objetos” mas sim suporta os conceitos OOP. Para uma aplicação ser realmente orientada a objetos é necessário que o projeto das classes seja orientada ao domínio, ou seja, Domain-Driven Design. E veja que no conceito DDD, a classe Service é procedural, como já foi dito.
Utilizar a melhor abordagem e tecnologia no contexto ideal. Este é o ponto.
Espero que tenha contribuido para o debate que é totalmente válido dentro da comunidade brasileira de software brasileira.
Abraço!
Poderia reescrever um trecho seu assim:
“Os ganhos da PF no domínio da aplicação (…) são inquestionáveis pra quem realmente conhece como projetar um design funcional.”
E ainda assim seria verdade. Quis destacar este parágrafo em especial porque ele diz mais respeito ao profissional do que o paradigma em si.
Sem dúvida.
Sabe uma coisa que me ocorreu agora, Kico? Fábricas de software… Essa ideia é tão ruim que ajuda até na disseminação desse problema de miopia linguística (adoção apenas de OO). Por quê?
Simples: fábricas têm que minimizar o custo de produção, não podem se dar ao luxo de pesquisas variadas ou de manterem uma diversidade de ambientes de programação. Imagine uma fábrica “especializada” em Java/JSF/Spring/Hibernate – qualquer coisa fora desse esquema, mesmo que tecnicamente superior ou até mais adequado às necessidades e aos valores do cliente, será reduzida à solução com a qual a fábrica tem “expertise”. Sei que não estou falando novidade nenhuma para você
. :-D
Ou seja, o ponto que quero destacar é que existe um modelo de trabalho horroroso na nossa área, e que é amplamente conhecido e adotado, que prejudica profissionais e clientes em vários níveis – um deles, a adoção do paradigma mais adequado à resolução do problema em vista.
Eu gosto muito de Java e sua orientação a objetos mas ao mesmo tempo me interesso por Scala e sua abordagem mista e sou apaixonado por aquela doidura que é Python. :-D Como profissionais, devemos cuidar com atenção da nossa “caixa de ferramentas”, sem deixar que modismos e fábricas de “software” ditem o que é ou não bom ou adequado.
Sabe Matheus… eu concordo com você em gênero número e grau máximo.
Que bom que estamos trabalhando juntos fora da linha de montagem hein? :)
Best thing ever!
Eu fico impressionado como essa estrutura de “fábrica de software” consegue ser perniciosa em todos os aspectos da nossa área!
Linguagens puramente funcionais surgindo e ganhando força acho que já abriram um pouco a mente do mercado, ou pelo menos a minha, que OO não é melhor em todos os casos.
Já trabalhei mantendo sistemas não OO e hoje mantenho um OO e acredito que alguns problemas são essencialmente os mesmos, um desenvolvedos pragmático e disciplinado, com uma visão clara do problema e das tecnologias que usa faz um bom programa, não necessáriamente um Programador Java, Delphi ou C.
oi Wellington. Este é meu ponto de vista. Falta pragmatismo na escolha do paradigma, que muitas vezes é simplesmente imposto independente do contexto.
Kico, acredito que você está usando o termo ‘pragmático’ de forma inversa.
O que estamos concordando com relação a crítica é exatamente o oposto: excesso de pragmatismo na definição do paradigma de programação.
Pragmatismo é tomar decisões rápidas, não necessariamente a melhor decisão. Tomar decisões focadas somente na prática e na experiência e não em pesquisas ou estudos. Focar somente naquilo que resolve seu lado, sem pensar no outro.
Em tempo, o título do texto é completamente contra ao que você tem afirmado que concorda que o problema não é OO mas seu uso. O questionamento é em relação ao mercado e não a abordagem.
Abs!
interrasante
Acho que o feeling da mensagem que ele quis passar ficou entendido.
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.
E o interessante da AOP é que ela não se aplica apenas a orientação a objetos.
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!
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?
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!
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! :)
É 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.
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. :)
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.
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. :-)
Nossa Everton, obrigado!
Também comecei com o msx :)
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.
O Nodejs vem ai pra acabar com esse cegueira de OOP.
Te falar que estamos em 2023. O js ficou mais OO do que nunca.
Node não conseguiu essa proeza. Pois JS mudou para ser OO com classes.
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
“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”.
Ótimo texto como sempre!