Dia desses vi um tuíte onde uma pessoa contava que estava tendo dificuldades em aprender Programação Orientada a Objetos (POO ou Object-Oriented Programming – OOP) mesmo depois de já ter estudado bastante. O tuíte me fez lembrar que também foi difícil no meu caso.

Se tem um assunto que me fascina é o aprendizado de computação. Nunca trabalhei com isso e nem sou um especialista mas sempre estou pesquisando sobre o assunto. Gosto desse assunto porque aprender computação sempre foi algo prazeroso pra mim e gostaria de entender porque isso acontece com algumas pessoas e com outras não. Queria saber se seria possível ensinar computação de um jeito que os aprendizes tivessem essa mesma sensação e esse mesmo tipo de emoção.

Mas com o tempo fui entendendo que as pessoas são muito diferentes e a forma com que cada uma delas encara diferentes tipos de aprendizados também varia muito. Pode até ser possível personalizar uma experiência para uma pessoa mas certamente esse método não funcionaria com outra.

Eu mesmo… sou péééssimo para aprender idiomas. E não é que eu não goste de estudar e aprender… é só que eu tenho que lutar muito mais que outras pessoas para avançar só um pouco. Cheguei até a achar que eu era só um “burrinho esforçado” mas hoje entendo que não existe gente burra. Tá… Pensando bem… Tem algumas que são burras sim… mas não é esse o ponto desse texto 🙂

Mesmo na computação tem assuntos que me exigem mais do que outros para aprender. Por exemplo: aprender uma nova linguagem de programação em um paradigma que eu já conheça é super rápido. Como já tenho referências de outras linguagens é basicamente construir paralelos entre umas e outras: “Ah! A sintaxe do Java parece com a sintaxe do C/C++.” ou, “Essa parte entre colchetes do Objective-C lembra um pouco do Smalltalk”, e assim por diante.

Mas quando é pra aprender um novo paradigma de programação, meu amigo, a coisa empaca muito. Já faz uns bons anos que bato na trave para aprender uma linguagem funcional mas não sai. A última “vítima” dessa tentativa foi Elixir. A linguagem parece incrível e me deixou super empolgado, mas… não evolui.

E sabe de uma coisa? Está tudo bem. Hoje eu tenho maturidade para entender que uma hora ou outra sai. Porque foi assim que aconteceu quando dediquei tempo para aprender Programação Orientada a Objeto.

No começo era o BASIC

Nos anos 80, algumas crianças privilegiadas como eu, tiveram contato com os primeiros microcomputadores que apareceram no mercado brasileiro. Eles se tornaram “acessíveis” (bota aspas nisso…) para a população e eram vendidos, para os pais, como ótimas ferramentas de aprendizado para os seus filhos. Era a ferramenta perfeita para tirar o gênio da cabeça das crianças.

Já para as crianças elas eram perfeitos videogames que ofereceriam horas e mais horas de diversão. No meu caso foi um pouquinho diferente: eu queria jogar meus próprios jogos e para isso eu precisava aprender a programar. E então tudo começou.

Essas máquinas vinham quase sempre com algum dialeto de BASIC para programar. E como essas máquinas eram lentas e limitadas qualquer código BASIC rodava na velocidade de uma tartaruga. Com freio de mão puxado. E por isso meu sonho de criar meu jogo foi sendo postergado… e postergado… e…

O jobzinho…

Certo momento da vida apareceu uma oportunidade para trabalhar como programador em uma imobiliária. Comecei o desenvolvimento em BASIC mesmo mas logo tive contato com uma linguagem mais apropriada para desenvolvimento de software empresarial: Clipper (Summer’87).

A linguagem Clipper era meio diferentona… não tinha número de linha nos programas. Não tinha comando GOTO para desviar o fluxo da execução… mas aos trancos e barrancos eu fui aprendendo…

Engraçado lembrar que eu achava ela uma porcaria porque não tinha GOTO e me obrigava a ficar fazendo loop dentro de loop dentro de loop com flag1, flag2, flag3, … pra controlar a execução. Imagina a maçaroca que era esse código (por isso você não deve se culpar por fazer código ruim quando está aprendendo…).

Logo depois desse trabalho eu tive contato com a linguagem Pascal e passei a focar mais em usar ela porque ela permitia desenvolver software gráfico (uma limitação do Clipper que só permitia gerar gráficos com bibliotecas proprietárias externas).

Foi só quando aprendi Pascal que também aprendi que esse paradigma de programação que eu estava usando desde o Clipper se chamava “Programação Estruturada”.

Foi também através do Pascal que tive meu primeiro contato com um paradigma “novo” que iria “revolucionar a forma de escrever software”: a Programação Orientada a Objetos.

Lembrem: eu era um brasileiro, morava no interior, não sabia nem o que era Internet, etc. As únicas fontes de informações que a gente tinha do mundo da informática eram as revistas, os livros e os ‘pirateiros’, profissional que conseguia as ‘cópias do original’ dos softwares que a gente usava. Ah! E software pirata sem manual! 🙂

O Turbo Pascal que a gente usava vinha com um negócio chamado “Turbo Vision” que era implementado com classes e objetos e permitia criar janelas em tela texto e usar com o mouse. Era bem massa… mas eu não conseguia usar porque não sabia direito nem o que era um “objeto”.

Como as revistas só falavam dessa tal POO e eu não conseguia entender nem usar eu até comecei a pegar “ranço” do troço. E eu tentei (o primeiro código OO que escrevi sobreviveu e está aqui. Era uma interface para usar mouse no DOS).

Mas não avancei daí mais. Pra mim, naquela época, objeto era um “struct com função dentro” (ou um “record com função dentro” pra quem prefere Pascal).

Nessa época eu até comprei um livro sobre programação OO mas desisti da leitura logo no começo porque não estava entendendo nada. Guarde essa informação.

Avança a fita e pula uma parte…

Depois disso eu decidi sair da profissão de programador e deixar a programação mais como hobby e investi meu tempo e aprendizado em coisas de mais baixo nível. Foi quando aprendi C, Assembly, comecei uma BBS, fiz estágio com Unix, mexi com Linux, etc…

Então tudo mudou novamente e fui trabalhar com Linux na Conectiva (com C) e conheci Python.

Python pra que te quero

Eu ainda pretendo escrever sobre a guinada que a linguagem Python proporcionou na minha carreira então vou economizar aqui.

Quando aprendi Python e usei ele em um projeto fui me acostumando cada vez mais a programar usando objetos. Mas só aprendizado prático mesmo: como criar uma classe, como criar “objetos” (o nome certo seria instância) dessa classe, etc. Criava aquele programão estruturado tudo dentro de uma classe só e tal… mas o código funcionava e as entregas eram feitas.

Lendo mais sobre Python e estudando mais Python eu acabei sendo exposto a mais e mais código orientado a objeto. E fui aprendendo, de forma orgânica, a programar assim.

A melhor forma de estudar programação é lendo programas. A melhor forma de aprender a programar é programando.
eu mesmo

Eu ia desenvolvendo código OO intuitivamente e por ‘imitação’ do código dos outros e, em paralelo a isso, os livros que eu passei a consumir iriam deixar de ser livros sobre “Python” e passariam a ser livros sobre “Programação Orientada a Objetos”. Como livro é caro eu decidi dar uma chance para um livro que eu já tinha comprado muitos anos atrás: Fundamentos do Desenho Orientado a Objeto com UML – Meilir Page-Jones.

Aquele livro que não fazia o menor sentido pra mim no passado consolidou todo aquele repertório que aprendi de forma orgânica programando em Python e “magicamente” a programação OO passou a fazer total sentido pra mim.

A partir desse ponto minha carreira profissional teve várias turbulências e tive que trabalhar com Java (detestei) e com Smalltalk (adorei), duas linguagens que também são OO e que possuem uma comunidade com bons fundamentos nesse paradigma. Ou seja, aprendendo e trabalhando com essas linguagens fui enriquecendo ainda mais a minha experiência nesse paradigma.

Quando trabalhei com Smalltalk li outros livros importante pra mim mas que não são específicos para POO:

eXtremme Programming Explained – Kent Beck
Design Patterns (ou Padrões de Projeto) – Gang of Four (esse é sobre POO)
Test-Driven Development by Example – Kent Beck
Refactoring – Martin Fowler
The Object Primer – Scott Ambler (esse eu gostei menos)

Seria interessante acrescentar um livro que ensine POO junto com uma linguagem à essa lista também. Mas isso varia muito de linguagem para linguagem então o melhor é perguntar entre os profissionais de cada uma delas qual é o livro mais indicado.

Precisa ler tudo isso pra aprender POO? Certamente que não. Eu diria até que alguns desses livros nem fazem bem para quem está começando. O que é importante mesmo é:

Ler muito código OO
Programar muito código OO
Ler uns livros, artigos, etc nas horinhas vagas
Descansar bem e cultivar uma vida saudável

Outra coisa que é muito importante reforçar também é que nem sempre o que serviu pra mim vai servir pra você. Se não estiver funcionando, tenha calma, dê um passo para trás, e tente outra abordagem. Tenha paciência com você mesmo e não desanime. O caminho tá cheio de frustrações para serem superadas.

E me desejem sorte… vou ali tomar mais um pouco de surra do paradigma funcional do Elixir…