No post anterior disse que o valor que mais apreciso em Groovy e Grails é a popularização que este propicia da plataforma Java EE. Mais do que simplesmente trocar de linguagem, não raro ocorre também a inclusão de um novo paradigma de desenvolvimento: a programação orientada a objetos (POO). Esta não é uma “mudança” fácil (se é que pode ser chamada de mudança: prefiro o verbo agregar), e acredito que ao expor minha própria experiência talvez possa ajudar aqueles que neste momento estejam passando por esta experiência.
Minha origem com TK-85 e MSX
O primeiro computador no qual pude por as mãos era um TK-85 em 1985. Meu pai era radioamador e naquela época você podia ligar um cartucho atrás desta maquininha e com isto transmitir e receber mensagens em código morse, substituindo o modo tradicional usando algum telegrafo.
Foi amor à primeira vista. Este computador era ligado a uma televisão preto e branco que servia de monitor. Não tinha disquetes ou CD-ROM. Se não me engano tinha apenas uma entrada para cartucho (ou algo assim) e outra para um gravador de fitas K7 aonde você podia salvar seus dados acredite se quiser. Eu tinha seis anos.
O que me lembro bem é que eu podia criar meus próprios jogos nele usando BASIC. Como eu fazia isto? Existiam livros nos quais vinha impresso o código fonte dos jogos. Então eu pacientemente os digitava naquele teclado de borracha linha a linha. Terminava tudo e em seguida mandava executar. Se tudo estivesse certo o jogo aparecia, caso contrário eu tinha de fazer tudo de novo. Este foi o meu primeiro contato com a programação. Então, se o Dijkstra estiver certo, sim: já comecei me mutilando.
É práticamente impossível ensinar boa programção a estudantes que tenham sido expostos anteriormente ao BASIC: como potenciais programadores eles se encontram mentalmente mutilados sem qualquer chance de recuperação. – Edger Dijkstra
O legal é que já naquela época eu percebia que mudando alguns trechos do código o jogo se comportava diferente. Foi também minha primeira experiência “hacker”.
Logo em seguida veio o MSX que era bem mais avançado que o TK-85. Eu devia ter uns sete anos e a história era basicamente a mesma: livros de jogos escritos em BASIC que eu alterava conforme ia digitando no computador.
E logo após isto veio o hiato de dez anos. Só voltei a programar quando fui para um curso técnico de informática em Belo Horizonte.
Visual Basic, Delphi, PHP, C, Pascal
De novo meu amigão Basic, desta vez sob a forma do Visual Basic 3 da Microsoft. Era coisa de louco o negócio: eu criava meus formulários só arrastando e soltando. Logo em seguida eu adicionava um evento ou outro nos meus botões e componentes e pronto: lá estava meu programa “profissional”. Meu primeiro “hit”, o MatMaker, foi escrito nesta linguagem. Era um “solucionador de problemas matemáticos”. Fui citado em diversas teses de mestrado, trabalhos de conclusão de curso, etc. Foi meu grande incentivo para seguir a carreira.
Mas o Visual Basic tinha um problema: eu precisava distribuir diversos arquivos junto com o executável. Foi quando conheci o Delphi, que gerava apenas um EXE. Então atualizei o MatMaker e esta foi por um bom tempo minha linguagem de programação favorita. Comecei no Delphi 3 e, como a maior parte dos delpheiros, terminei no 7.
Logo em seguida brinquei um pouco com C, Pascal e PHP. Mas não era nada muito avançado: basicamente programação que tentava ser estruturada. Olhando hoje para aqueles sistemas da vontade de estapiar aquele moleque de 17 anos. :)
Primeiro contato com orientação a objetos no Delphi
Em 2001 lancei meu primeiro produto. Se chamava Livreiro: era um ERP vertical para livrarias feito em Delphi (lembra aquela versão gratuita do Delphi 5 que vinha em uma revista?). Naquele momento já sabia programação estruturada e, na prática, o que eu realmente fazia era programação baseada em eventos de interface.
O Livreiro foi crescendo e com isto a manutenção foi ficando complicada. Era preciso ter código reaproveitável. Surgem meus primeiros componentes sob a forma de DLLs. Basicamente um amontoado de funções e formulários que eu usava o tempo inteiro.
O próximo passo foi a orientação a objetos. Eu não via uma classe como uma classe, mas sim como uma maneira de eu digitar menos código. Pegava o código que usava em diversos pontos e colocava em uma classe. Logo em seguida o que eu fazia era simplesmente criar algo que herdasse daquela classe. E este foi meu primeiríssimo contato com a orientação a objetos. Não era Programação Orientada a Objetos, mas sim Baseada em Objetos no máximo, tal como eu já fazia com o Visual Basic.
De mecanismo de reuso à criação de objetos reais
No meu primeiro estágio tive a que talvez foi a experiência mais emocionante da minha carreira: desenvolvi o sistema de comissionamento da Mina de Brucutu. Enquanto programava eu observava que haviam “categorias de objetos”, cada uma representando uma funcionalidade diferente do programa.
Quando liguei a palavra “categoria” ao termo “classe” a coisa passou a fazer sentido. Finalmente entendia O QUÊ eram as tais das classes. Eram categorias de objetos, cada qual com a sua própria responsabilidade. Pela primeira vez escrevi um sistema REALMENTE modular, REALMENTE expansivel.
Cada classe passava a representar algo como se fosse uma personagem em uma peça de teatro. E elas interagiam entre si de tal forma que aquele ato que encenavam era na realidade o meu sistema.
Padrões de projeto e Java
Aquele sistema foi feito em Visual Basic. Então eu não tinha orientação a objetos, mas programação baseada em objetos pois o Visual Basic 6 não tinha herança direito. Eu no máximo conseguia simular algo próximo. No entanto quando aprendi Visual Basic 3 estava surgindo um negócio chamado Java, que aprendi lendo um livro chamado “Aprenda Java em 24 horas”.
(Só pra lembrar, mais ou menos naquela época a Microsoft havia feito a CAGADA de lançar um VB.net completamente incompatível com a versão anterior. Muita gente foi pro Java com medo de se ferrar de novo com a mesma história. Isto rendeu um post aqui em 2008.)
Aquele livro era massa! Mas não falava muito em orientação a objetos: só o básico. Sabia que existia herança, interfaces, um tal de polimorfismo e só. De resto até então Java só me servia para escrever alguns applets (alguém lembra disto?) bem tolos.
Para os próximos projetos Java parecia (e era) uma opção interessante. Comprei então o “Java como Programar” dos Deitel e aí sim aprendi o que era polimorfismo, herança, etc. E havia também o GUJ, que me ajudava HORRORES com algumas discussões que eram simplesmente fantásticas.
Eu ouvia falar de padrões de projeto mas não entendia o que eram. Então comprei dois livros: o “Padrões de Projeto” original e o “Use a cabeça: Padrões de Projeto“. Foram livros importantíssimos na minha formação pois pela primeira vez eu via que outras pessoas enfrentavam os mesmos problemas que nós tinhamos na empresa! Ao mesmo tempo foi também um alerta, pois foi quando vi também que o uso de padrões apenas por serem padrões pode ser a maior cilada (escrevo sobre isto um dia).
Como liguei as palavras “categoria” e “classe”
Em 2001 comecei o curso de Filosofia na UFMG. E lá entrei em contato com os textos de Platão e Aristóteles. Diversos comentadores usam a metáfora do “mundo das idéias” do Platão, então eu pude ver algo parecido com “classes”.
Junto a isto vinha o texto “Categorias” do Aristóteles que, mesmo não tendo o lido, tomei contato sobre o mesmo através dos comentadores, ou seja, quem acidentalmente me preparou para a orientação a objetos foi o curso de Filosofia da UFMG. Sei que não é o caso da maior parte dos programadores, então fica a dica aqui: pesquisem a respeito.
A transição foi fácil?
Não foi fácil: foi horrível. Eu estava habituado ao modo de trabalho anterior que por mais que critiquem era e é extremamente produtivo. Primeiro montavamos a interface e em seguida iamos enriquecendo o sistema com funções compartilhadas, módulos, o banco de dados e o resto. Conforme ia entrando no Java parecia que era um modo de trabalho extremamente retrógrado.
Conforme o tempo foi passando vi que aquela minha impressão era só uma impressão. Meus códigos iam melhorando conforme ia me habituando com a orientação a objetos. Eu conseguia ter uma visão mais ampla do sistema, conseguia gerar soluções que eram fáceis de serem alteradas no futuro. Então aquela perda da interface “arrastar e soltar” começava a valer muito à pena.
Diversos colegas não conseguiram fazer a transição. Na primeira dificuldade sempre acabav am voltando para o VB com a promessa de depois refazer a coisa em Java ou C#, o que nunca ocorria. Há sempre um medo na mudança: o segredo é perceber que o ganho compensa no final. Para mim compensou bastante: fez minha carreira. Foi a mudança fundamental.
Sobre este medo, é sempre bom terminar com este vídeo da Carli Fiorina: “The Dynamics of Change and Fear”:
http://www.youtube.com/watch?v=w3IbKbDhfKw
PS: depois que você supera esta barreira (acredito que ela sempre surja no momento em que você rompe o primeiro paradigma com o qual se sentia seguro) a coisa muda. Tudo fica mais fácil: daí surgiram diversas outras linguagens como por exemplo Javascript, Groovy, Lisp, Clojure, C++ e tantas outras que tem preenchido minha vida desde então. Acredite: vale à pena. Insista.
Deixe uma resposta