20 anos depois, e ainda não entendemos reusabilidade
Enviado por Cindy Dalfovo (cindy·dalfovoΘgmail·com):
“Quando eu comecei a programar, eu fiquei apaixonada, pela maneira de construir algoritmos lógicas que faziam coisas incríveis. Eu gostava disso, eu gostava dessa elegância, dessa brincadeira.
Não foi o que eu encontrei quando comecei a trabalhar: eu tinha de fazer malabarismos com bibliotecas até convencê-las a fazer o que eu queria. Por quê? O que deu errado na hora de escrever código reutilizável? Na hora de escrever os sagrados componentes e bibliotecas que deveriam tornar o desenvolvimento de sistemas complexos algo menos complicado, algo parece ter se encaminhado para o lado do excesso de tarefas e utilidades e para longe da simplicidade de uso.
Esse post é apenas um longo desabafo acerca desse assunto.” [referência: diskchocolate.com]
• Publicado por Augusto Campos em
2010-04-26
@brlinuxblog
Feed RSS
http://www.perl.org.br/Artigos/AprendaAProgramarEm10Anos
Bem, isso depende mais dos desenvolvedores que criam o código para ser reutilizável do que dos que vão usar o código.
Más tem muita coisa boa por aí, por exemplo a porrada de frameworks para java, as bibliotecas gráficas, matemáticas etc. :)
“Frameworks para java” e “coisa boa” na mesma frase é difícil de engolir. :-)
Trollagem à parte, a verdade é que pouca gente realmente entende orientação a objeto o bastante para reutilizar código do jeito certo — e às vezes OO nem é a melhor solução, o que torna tudo mais complicado.
É que tem muita gente que acha que sabe programar e faz código salsicho. Já vi muitos desses códigos salsicho por aí. A sorte é que nem todos os códigos são assim.
Eu herdei um sistema em Delphi onde vários módulos criam um form de nota fiscal, preenchem os campos visuais “na mão” e clicam no botão “Salvar” para gerar um nota fiscal… Há uns dias, me sugeriram que este mesmo sistema deveria ter um web browser interno para acessar o site da Prefeitura e preencher os campos dessa mesma forma para criar NFS-e.
Realmente, a desolação e a perda da fé são companheiras constantes nessa profissão.
Estes problemas citados pela srta. Dalfovo são bem comuns em “linguagens de programação” como Java e PHP.
Como não sou programador (estou mais para ‘code monkey’ segundo a definição dela, que está correta), não posso dar pitaco. Mas ao menos em C eu não vejo meus programas “quebrarem” sem mais nem menos de uma versão para outra, na hora de compilar.
Linguagem fácil atrai desenvolvedor ruim. Por isso é que há muitos salsichos escritos em Java, PHP e outras linguagens fáceis. Mas não se deve culpar a linguagem por isso, e sim o desenvolvedor.
Esse elitismo do tipo “bah, em C essas coisas não acontecem” dizem mais sobre a falta de compreensão dos problemas de usabilidade do que sobre a linguagem em si.
“e às vezes OO nem é a melhor solução”
Fabio FZero, te cuida. Ao dizer isso pode sofrer retaliações de usuários mais exaltados de Java. E ruby ultimamente.
OO, definitivamente, não é para reutilização em larga escala. Já perceberam isso, o discurso agora é OO facilita a manutenção, já que prioriza a clareza do código.
Sou desenvolvedor mais antigo, utilizo o antigo modelo procedural de programação.
Mas sempre quis aprender OO, mas nunca consegui ver uma funcionalidade para o mesmo no meu ramo, criação de aplicações como PDVs, ERPs, …
Sei que por ter aprendido a programar de forma procedural e utilizá-lo a anos fica bem mais difícil a compreensão do OO. Mesmo quando utilizo Python, aonde tudo é um objeto, a linguagem não obriga o programador a usá-lo.
Sempre tinha em mente que com o OO se reduzia muitas linhas de códigos, havia menos problemas de erros, os códigos ficavam mais “limpos”, e com uma manutenção mais fácil.
Mas na prática não é bem assim, primeiro temos que aprender e bem a usar o OO, o que não é nada fácil. Os objetos a serem criados tem que serem bem pensados para que possamos reaproveitá-lo, ou seja maior dificuldade de programação e alem disso li em sites que a programação OO é menos performática que a procedural, isso procede?
Sei que o OO tem o seu valor, principalmente nas IDEs gráficas, mas para um programador no ramo de PDVs, ERPs,… vale a pena?
Os objetos a serem criados tem que serem bem pensados para que possamos reaproveitá-lo, ou seja maior dificuldade de programação
É que muita gente, ao desenvolver o sistema, já vai direto à programação, ao código. O correto é fazer a análise do programa, com casos de uso, diagrama de classes, diagramas de sequencia, etc. Aí, com um bom projeto de software, a implementação se torna mais fácil e não precisa-se pensar como vão ser as classes, pois o formato delas é definido nesse projeto. E, como muitos prohramadores já saem digitando código sem pensar, aí aparecem os salsichos.
e alem disso li em sites que a programação OO é menos performática que a procedural, isso procede?
Isso varia de linguagem para linguagem, depende também da plataforma. Há linguagens orientadas a objetos mais rápidas que linguagens procedurais e vice-versa.
Sei que o OO tem o seu valor, principalmente nas IDEs gráficas, mas para um programador no ramo de PDVs, ERPs,… vale a pena?
Vale sim, e existem muitas dessas aplicações em linguagens orientadas a objetos.
“Vale sim, e existem muitas dessas aplicações em linguagens orientadas a objetos”
Claro que existem muitas aplicações em linguagens orientadas a objetos, mas a maioria delas não usa OO, só utilizam a linguagem, mas a programação na grande maioria é procedural.
OO numa linguagem criada para ser OO é ótimo; numa linguagem recauchutada para virar OO é uma M…
E OO é perfeita para muitos casos, mas para outros simplesmente não encaixa de jeito nenhum. Definitivamente não é possível ser radical, bananas são bananas e laranjas são laranjas.
Eu francamente tenho pavor de frameworks, e nem sei se estou usando o termo correto.
Quando tento utilizar algo pronto, tenho a impressão que é infinitamente mais fácil desenvolver qualquer coisa do zero do que aprender um framework complexo pra usar um ou dois recursos.
(eu já tinha comentado, mas meu código nao apareceu D:)
O que eu achei interessante foi ver quantas pessoas tem a mesma desolação que eu :p
@Fabio FZero
Concordo sobre OO nao ser solução para tudo mas as pessoas acabam utilizando-a pq praticamente só se ensina isso, e se ensina mto pouco de programação funcional, e procedural apenas para dar uma minima base… é complicado. As pessoas acabam usando Java OO pq eh o q todo mundo usa, mesmo quando nao seria o mais indicado…
A linguagem que vejo mais desenvolvedores com código reutilizado é o Java, onde a maioria das literaturas já formam o desenvolver pensando em componentes e reutilização. Prática que poderia ser usada em qualquer outra linguagem…
@Bremm
Dar uma olhada no X.org ou mesmo na api do windows da sério 9X e você passará a ter pavor de C (eu amo essa linguagem).
Agora sobre OO, o grande problema não é a perspectiva OO e sim os próprios programadores, posso citar diversos exemplos para isso.
Um deles é que para começar a fazer um programa OO tem que pensar OO, entretanto é pura perda de tempo querer pensar em reutilização de código sem ter visto repetição de código, da mesma forma que é difícil pensar em diagrama de classes a alto nível se o que interessa é o baixo nível (por isso que acho a UML quase que uma perda de tempo).
Na realidade a idéia de programar usando OO vem com a própria evolução do software que esta fazendo, neste caso começasse a perceber coisas que se encaixaria melhor em classes e objetos que na construção braçal, por tal razão esse conceito pode muito bem ser utilizado até em linguagens procedurais.
Mas o que falta a muita gente é buscar facilitar seu próprio trabalho, na empresa onde trabalho a palavra reuso é que mais bate em meus projetos, desde de a criação de plugins jQuery para facilitar meu trabalho a criação de classes auxiliadoras para reduzir o transtorno de programar no Struts (quero que esse framework morra), pena que o que criei para tornar o trabalho no Struts menos sofrido teve de ser deixado de lado por causa de um builder que a própria empresa anda fazendo para facilitar o processo de construção de XML (eu odeio tanto a configuração do Struts que criei algo somente para me tirar dessa tarefa estúpida).
A idéia por trás da OO é que você de fato programa mais, entretanto reusa muito mais, quando já se tem bastante conteúdo construído no final o processo se torna mais simples de trabalhar sem ter que refazer a roda.
Um exemplo prático disso foi um pequeno framework que fiz que se encontra no seguinte endereço (http://github.com/cristovao/SKD-Framework) que criei para substituir o Hibernate para tarefas mais simples (e por eu odiar o Hibernate), no caso com o framework que criei só faço apenas as classes para representar as tabelas e digo quais dos atributos são chaves primárias, no final tenho meu mapeamento ORM da forma mais simples e direta possível (nada de inner joins de classes, para mim o certo é usar views do banco de dados) e venho usando ultimamente da forma simples possível sem XMLs de configuração e nada de um milhão de annotations, no máximo um annotation para dizer qual tabela representar a classe e se um atributo é chave primária.
Outra coisa que fiz usando a perspectiva OO foi uma classe model que uso para representar entidades no banco de dados em sistemas PHP5, apenas faço minhas classes herdarem essa classe dizer quais são os atributos e pimba já tenho todo o mapeamento ORM sem ter que escrever SQL a coisa fica tão simples que fico entediado de fazer classes que tem nomes de tabelas, já que a programação em si se torna inexistente (acho que vou fazer um scaffold só para tratar disso).
Ontem consegui uma grande vitória, receber uma tarefa para eliminar uma gambiarra, agora tenho o script pronto e amanhã pretendo usa-lo para mudar a face do pesadelo das gambiarras.
Por tais razões eu discordo de muitos dos comentários que criticam a OO, já que o problema são os desenvolvedores (deveriam se chamar de gambiarrizadores) que na maioria das vezes pensam com a cabeça de dez anos atrás, dificilmente pensam dez anos no futuro, já passei por empresas que dizem que querem seus sistemas em OO sem saber o que é OO e já falei com pessoas que pensam que OO se resume a GUI e já vi idiotas que acreditam que DAO é produtivo (por essa razão criei um framework chamado Simple Kill DAO Framework (SKD)).
Para mim uma boa biblioteca se resume no mínimo de classes possíveis para uso, para controle 3 classes para mim já é demais.
Esse assunto me deixou aliviado!
Enfrento o mesmo problema na Pedagogia (?).
Explico: Para criar cursos a distância uma metodologia de trabalho aproxima seu desenvolvimento às Ciências da Computação. Entidades abstratas em EAD, como os Objetos de Aprendizagem, são baseadas, em parte, na teoria de orientação a objetos.
Mesmo se você trabalha seriamente com esta abstração enfrenta sérios problemas de normatização que impactam no desenvolvimento de cursos e na sua posterior reutilização na mesma ou em outra plataforma de EAD (Moodle, por exemplo).
Achava que esta era uma limitação do staff educacional, mas lendo seu artigo posso transpor todos os problemas apresentados para o grupo dos programadadores, usuários máximos desses modelos.
Simplificando, OO é imposto pelo Java e pelas faculdades, não necessariamente é a melhor forma de programar, quem dita isso é o mercado de trabalho.
OO = Frameworks = IDE = JAVA
Ou seja quem utiliza Java ou qualquer Framework ou IDE gráfica acaba usando OO, mesmo sem saber.
Concordo que OO tem seus méritos e seu espaço, o problema é que a linguagem procedural esta esquecida e a nova geração de desenvolvedores acaba sendo obrigada a aprender e usar o OO em tudo, mesmo não sendo a melhor opção para todos os casos.
A principal utilização do OO é os geradores de programas. Com isso o programador na maioria do casos se esconde atrás do Framework e quando é preciso algo mais ele se estrepa. Mas por outro lado é extremamente produtivo para fazer coisas ‘padrões’, principalmente para Sites, Blogs, …
A grande evolução que as linguagens POO prometiam trazer é mais uma onda.
Até porque os grandes softwares, como os sistemas operacionais, todos são escritos utilizando C. E acho que foi aqui que li que o C retomou a liderança no ranking das linguagens de programação, isso prova que POO esta em baixa.
Não existe nada que uma linguagem OO posa fazer que a procedural não faça, já o inverso não é verdadeiro.
O melhor conselho que tenho a dar é “ Utilize a linguagem, ou o tipo de programação que tu domina melhor o resto é bobagem “. Claro que este conselho é para o desenvolvedor que pode escolher, já se depender do mercado de trabalho ai tem que ir de Java, C#, .NET… que são as tecnologias ensinadas nas faculdades e usadas no mercado de trabalho.
Depois que me mudei para Toronto percebi que o grande, enorme problema MESMO é que o mercado brasileiro está viciado em Java. Melhor dizendo: os gerentes e “consultores” (aspas necessárias) de TI se fecham em Java.
Existem algumas razões para isso:
- é o que as faculdades ensinam;
- muitos que estudam computação não gostam realmente de programar e entraram nessa só porque é “uma carreira que dá dinheiro”;
- preguiça de estudar novas tendências e linguagens (resultado direto do item acima).
Aqui no Canadá o pessoal está usando Ruby e Python em larga escala em ambientes enterprise, por exemplo – especialmente Rails. Existem sistemas Java e .net também, claro, mas a coisa é bem mais distribuída.
Falando em Rails, esse framework é um ótimo exemplo de OO sendo usada direito. Na verdade muito do hype em torno dele vem da admiração dos *programadores* pela framework – ao contrário da imposição de ferramentas feita pelos *gerentes* que acontece no mundo Java.
O fato é que OO bem usada resulta em reutilização de código e especialização através de heranças – dois conceitos básicos do Rails, que também usa largamente meta-programação e mixins. No fim, o código da aplicação fica de fato muito mais curto do que em qualquer framework Java.
(Ah, e antes que algum troll acorde: os problemas de escalabilidade das versões iniciais já foram resolvidos há bastante tempo.)
O Django faz o mesmo pelo Python, mas por alguma razão está tendo adoção mais lenta. Isso pode mudar com a popularização do Google App Engine, mas isso é outro papo.
Sei lá, o OO também depende do SO em muitas coisas.
Tem um sistema aqui (mas é de terceiros) que foi feito em delphi, como eu sei ?
Bem, o programador deixou claro através das linkagens dinamicas com DLLs (sim dá para por forms lá) e bpl’s. O resultado disso é que sempre que dá um erro em pontos aleatórios. Eu noto que o programa dessa softhouse tem vazamento de memória e vai comendo recursos ao poucos até estinguir os recursos do Windows. Por incrivel que pareça, trocamos “Variable does not exists” dos sistemas em clipper, por “Este programa executou uma tarefa ilegal e será capotado”. O problema não está na linguagem, mas nos programadores, tem muito cabeça-dura nesse ramo.