Semana Alagoana de Software Livre
Postado por Osvaldo Santana
Ontem de noite eu cheguei em casa depois de ter ido à Maceió ministrar 2 palestras na I Semana Alagoana de Software Livre.
Ao desembarcar lá no dia 26 para o primeiro dia do evento fui logo recebido pelo Maurício Teixeira (netmask) e aguardamos por um instante no aeroporto até que o Hélio Chissini, que também participaria do evento, chegasse.
A partir daí foi tudo festa. A primeira edição da Semana Alagoana de Software Livre foi organizada pelos alunos de graduação da FAL em conjunto com os integrantes do LUG-AL. Por ser a primeira edição do evento a programação não era muito extensa (3 palestras por dia) mais alguns mini-cursos e uma install fest que ocorreu no último dia do evento.
Eles também experimentaram um modelo diferente dos outros eventos colocando todas as apresentações no período noturno. Isso ficou muito legal porque permitiu que pessoas que trabalham durante o dia pudessem participar do evento. É uma idéia genial que sem dúvida poderia ser copiada por outros eventos do mesmo tipo.
Como o evento foi organizado pela turma de Sistemas de Informação da FAL eles cobraram a inscrição para o evento e para os mini-cursos ministrados. Também venderam ingressos para uma festa que encerraria o evento e camisetas. A verba arrecadada será usada para cobrir os gastos com a festa de formatura da turma.
Levando-se em conta que foi o primeiro evento deles, que o LUG-AL ainda não tem muitos integrantes e o evento foi pago, o público presente foi excepcional. Segundo os organizadores estiveram presentes uma média de 200 pessoas/dia.
O tratamento dispensado aos palestrantes (eu incluso) merece uma referência à parte. Me cansei de ouvir o nosso “guia turístico” (netmask) repetir: “Palestrante aqui é rei!”.
Eles nos hospedaram em um hotél “5 estrelas” (não sei se são cinco estrelas porque o hotel tem apenas 1 mês de funcionamento e acho que não foram catalogados pela Embratur) que dispunha de TV de LCD e ar-condicionado inteligente em todos os quartos que ficavam de frente para uma das praias mais bonitas de todo o Brasil.
Frequentamos os melhores bares e restaurantes da cidade e as contas simplesmente não chegavam às nossas mãos para serem pagas. A organização do evento arcou com todas as nossas despesas.
Fica aqui o meu agradecimento ao pessoal de Maceió que organizou o evento (em especial para o Maurício) e a recomendação para todos aqueles que queiram fazer um evento de sucesso que se inspirem no trabalho que essa turma fez.
Autores Falsos de Textos Falso
Postado por Osvaldo Santana
Recebi um e-mail dessas correntes de uma amiga e respondi à ela alertando para o fato e aproveitando pra emitir um pouco das minhas opiniões sobre política e eleições.
Não quero convencer ninguém a votar em ninguém. Também não quero saber de discussões fervorosas sobre política nesse blog então, excepcionalmente para este post, irei desligar a opção de comentários.
Segue o conteúdo do e-mail:
Oi Amiga, Esse texto não é do Arnaldo Jabor. Já dá pra perceber pelo estilo e pela falta de responsabilidade de chamar o Presidente da República (note as letras maiúsculas) de "retardado". Tem gente que gosta do Lula e tem gente que não gosta do Lula, mas respeitá-lo é uma obrigação de todo mundo, afinal, ele é o atual Presidente e teve uma votação de 66% na primeira eleição e caminha para outra eleição onde ele vai chegar próximo desses 66%. Se são votos de pessoas desinformadas não foi culpa dele, afinal, foi a primeira vez que ele governou o país Além do autor desse texto ofender o Presidente da República ele ainda fala que eu tenho "problemas mentais", afinal, eu votaria no Lula se meu Título de Eleitor tivesse sido transferido aqui pra Pernambuco. Eu não tenho problemas mentais, não sou analfabeto (digo até que escrevo melhor que esse falso-arnaldo-jabor abaixo) e faço parte da classe Média brasileira. Mas a classe Média que eu participo é aquela que entende que é possível abrir mão de algumas coisas materiais para ajudar aqueles que precisam. Mesmo que essas pessoas gastem esse dinheiro pra assistir um jogo do "mengão" e tomar cerveja eu não quero que minha consciência pese ao saber que essas pessoas antes de poderem torcer para o mengão e tomar uma cervejinha (como eu faço hoje) costumavam morrer por causa da fome. Também não podemos nos esquecer que se existe uma parcela dos beneficiados dos programas sociais que "tomam cerveja" existe uma outra parcela presumivelmente muito maior que tem colocado seus filhos na escola e comprado comida, caderno e lápis pra eles com esse dinheiro. Eu sou um "classe média" do sudeste que por acaso vim trabalhar no nordeste e pude perceber que as "diferenças sociais" desse país por aqui são muito maiores do que as diferenças nosul/sudeste do país onde morei. Aqui eu vi a babá do meu filho chorar e dizer "que nunca havia ganhado tanto dinheiro na vida dela" depois que a registrei com 1 salário mínimo. Imaginem 1 salário mínimo é ultrajante pra mim e um 'salarião' para ela e só foi possível eu registrá-la porque o Lula criou um programa de restituição do INSS recolhido para ela em meu Imposto de Renda. Os 4 netos da minha babá recebem dinheiro dos programas do governo. São todos meninos espertos, frequentando a escola e bem alimentados que brincam junto com meu filho sempre que se encontram. É nesse mundo 'igual' que eu gostaria de ver meu filho crescer. Valeu, Osvaldo PS. Os meninos estão na escola também porque os programas do governo obrigam a isso. É obrigação dos pais manter os filhos na escola para receberem o benefício, diferente do que a candidatura PSDB alega. On 10/25/06, Amiga Minha wrote: > Um texto de Arnaldo Jabor - PERFEITO E PESADO! > > Me revolto ao ver que pessoas esclarecidas tem a ousadia de apoiar a > pessoa mais retardada deste país: LULA. > > Só uma pessoa que padece de problemas mentais para nunca ter ciência > do que se passe ao seu redor....ou seja, vive aérea. > > E tem mais, voto sim no Alckmin, que seja ele ladrão. Voto pq não recebo > cesta básica, não tenho bolsa família, bolsa escola, auxílio gás, não > participo do fome zero, pelo contrário, faço parte da classe que fica > FORNECENDO dinheiro pra esse ser maldito que teve a infelicidade de > nascer neste país, ficar bancando parte da população que está super > satisfeita com os auxílios governamentais e se contenda ter grana no > final de semana pra beber cerveja e ver os jogos do Flamengo. > > Pobre de mim, alma atormentada que luta pra ter algo e é massacrada pela > ignorância da massa brasileira. > > Pobre de mim que tenho que engolir o maldito barbudo, pq no Nordeste e > Norte do país, não há desenvolvimento cultural e informações suficientes > para esclarecer a real conjuntura vivida. > > Pobre de mim que tenho vergonha de morar em um país que elege Paulo > Maluf e os ladrões do mensalão e, completam o circo com Clodovil!!! > > É vergonhoso ser eleitor neste país! > > A VERDADE ESTÁ NA CARA, MAS NÃO SE IMPÕE > > ARNALDO JABOR
Software Livre: você contribui com código?
Postado por Osvaldo Santana
Discurso padrão: serei um pouco contundente em alguns trechos deste artigo. Farei algumas generalizações para facilitar mas, acredite, alguns brasileiros simplesmente não se encaixam no público alvo deste artigo.
Desde antes do Linux surgir ou da idéia de Software Livre ser conhecida entre as pessoas aqui no Brasil eu já era defensor deste modelo. Quando eu desenvolvia meus sistemas em Clipper para os meus clientes tratava logo de deixar o código fonte com eles e já deixava claro pra eles que se eles preferissem entregar a manutenção para outro desenvolvedor eles estariam livres para fazê-lo.
Ok, essas liberdades que eu dava para meus clientes não chegavam nem perto das reais liberdades que os softwares licenciados pela GPL, por exemplo, oferecem hoje. Mas as minhas intenções eram as mesmas.
Desde que entrei de cabeça neste universo livre percebi que todos esses softwares que existem hoje foram ao menos iniciados a partir de esforços voluntários de uma comunidade de desenvolvedores, artistas, documentadores, etc.
Esses voluntários estão espalhados por todos os lugares do mundo inclusive no Brasil. E é sobre a participação brasileira que gostaria de comentar.
Atendendo à um pedido de um colega de trabalho comecei a fazer uma pequena pesquisa informal e não-científica sobre a participação de brasileiros no desenvolvimento de software livre e fiquei muito feliz em ver que esses brasileiros contribuem com vários projetos. Obviamente ainda é uma fração praticamente irrisória de contribuições se compararmos com países da europa, por exemplo, mas já é alguma coisa.
Essa pequena pesquisa também serviria para coletar alguns nomes de profissionais que fizeram alguma colaboração com código para algum desses projetos para buscar alguns talentos para vir trabalhar comigo na mesma empresa onde trabalho.
Aí veio a decepção. Infiltrando mais à fundo nas colaborações desses brasileiros foi possível notar que a contribuição nossa com código para esses projetos é tão pequena que faz qualquer um ficar decepcionado.
É claro que contribuir com documentação, traduções, arte, divulgação e uso é importante para esses projetos. Mas e o código? Software Livre não se cria sozinho! Você não liga um computador e o código pula na tela. Não é tão simples assim.
Sempre que eu falo que precisamos colaborar com código para os projetos já escuto logo um: “ah… mas eu traduzi o sistema foobar para o português!” ou “eu fiz um tutorial de instalação da distro ble”. Legal. Parabéns! Mas e aquele bug aberto no bugtrack do sistema foobar? E aquela funcionalidade que as pessoas estão implorando (inclusive você)?
Vamos esperar até o dia que o bug se feche sozinho? Ou que o desenvolvedor principal do projeto use o tempo dele para melhorar a minha vida?
Chegou a hora de parar de nos desculpar por não contribuir com código para os projetos simplesmente porque “eu traduzi as mensagens de erro do kernel!” e começar a anexar patches e fazer commits nesses projetos.
Eu me incluo entre esses “colaboradores de meia pataca”. Procurei pelo meu nome no Code Search do Google e achei um horror o resultado. Afinal já fazem mais de 6 anos que lido com Software Livre e meu nome apareceu em apenas algumas dezenas de ocorrências e, pior, em menos de uma dezena delas a minha contribuição tinha sido com código.
Então eu gostaria de lançar o desafio aqui: vamos todos repetir uma busca por nossos nomes no Google Search daqui a algum tempo e vamos ao menos dobrar o número de ocorrências deles por lá? Mas só vale contar contribuições com código!
Propaganda: Se você quer contribuir com código e quer começar por uma linguagem fácil e poderosa eu já recomendo à você que dê uma olhada na linguagem Python 
Turbogears, Django e Plone
Postado por Osvaldo Santana
Nesse feriado resolvi dedicar um tempo para testar os frameworks de desenvolvimento Web disponíveis em Python para poder escolher um deles e iniciar o desenvolvimento de um pequeno sistema para cadatro de “Palestras e Palestrantes”. Para essa tarefa escolhi os 3 frameworks mais usados atualmente: TurboGears, Django e Zope/Plone (o Plone não é um framework, mas vou tratá-lo assim para simplificar o texto).
Eu já conhecia um pouco esses frameworks e até já tinha um preferido (TurboGears) e um outro com o qual já tinha um certo preconceito (Zope/Plone). O preconceito com o Zope/Plone nasceu com outras tentativas de aprender a usá-lo.
O Sistema
A idéia do sistema é permitir que a gente possa cadastrar os arquivos com as palestras e cursos ministrados por uma equipe e juntamente com esses arquivos manter informações relacionadas à essas palestras tais como: palestrantes/professores aptos, público-alvo, requisitos da sala de apresentação, etc.
Posteriormente o sistema também permitiria cadastrar datas de eventos, dados sobre as viagens dos palestrantes/professores e posterior mente fazer a solicitação de reembolso para as despesas destes.
O que foi feito
Apesar do sistema ter um escopo relativamente pequeno seria complicado conseguir terminá-lo em um único final de semana (mesmo prolongado) levando em conta que eu iria aprender e testar todos os frameworks que utilizaria. Então resumi o teste apenas ao cadastro de palestras. A parte estética do software também não seria importante mas uma avaliação sobre como usar as linguagens de template de cada framework fazia parte da experiência. Em alguns casos eu sequer terminei a implementação porque já tinha compreendido o funcionamento do framework e não havia mais a necessidade de finalizar o teste.
A seqüência que usei para os testes foi: Plone, TurboGears e Django.
O Plone
Depois que assisti à uma apresentação do meu amigo Xiru durante a I PyConBrasil fiquei muito tentado a experimentar o Plone com Archetypes e o ArchGenXML (criado pelo próprio Xiru). Achei que era um bom momento para brincar com isso e em 1 dia eu coloquei um Zope e um Plone pra funcionar em minha máquina. Demorei todo esse tempo porque fazia questão de ter as últimas versões estáveis dos dois programas e porque gostaria de fazer a instalação manualmente a partir dos fontes (isso não é necessário pois existem scripts automatizados para instalação disponíveis no site do Plone).
A instalação foi fácil, mas colocar ela pra funcionar demorou um tempão. Os problemas que enfrentei basicamente eram relacionados à versão do Zope que eu estava usando e a versão de um “produto” chamado Five que acompanha o Plone. Para resolver este problema simplesmente instalei outra versão de Zope e tudo começou a funcionar perfeitamente.
Conferi no catálogo de produtos do Plone (produto é o nome dado às extensões no universo Zope/Plone) para verificar se já não existia um produto que fazia algo semelhante ao que eu precisava e encontrei algumas coisas interessantes para testar. Nada do que eu testei fazia exatamente o que eu queria mas certamente seria muito mais negócio adaptá-los à inventar algo novo.
Mas a minha intenção era brincar com o ArchGenXML e então decidi reinventar a roda só para sentir o gostinho de usá-lo. Se no futuro eu fosse escolher o Plone eu partiria para reaproveitar esses produtos existentes e provavelmente jogaria o que eu tinha feito fora.
Segui passo-a-passo o tutorial do ArchGenXML e posso confirmar: funciona. Desenhei o esboço da minha aplicação no Poseidon UML Community Edition (recomendação do próprio Xiru), gerei o código, instalei e usei. Foi simples assim. O único contratempo que enfrentei foi o de ter de lembrar de reiniciar o Plone depois de ter instalado uma versão nova do meu novo produto criado.
Como eu já disse eu desenvolvi um preconceito muito grande com a dupla Zope/Plone (mais por causa do Zope) e obviamente isso fez com que esse sistema saísse atrás na corrida pela minha escolha. Mas ele me surpreendeu. Durante essa semana vou fazer umas perguntas para o pessoal do TcheZope e dependendo do que eu ouvir o Plone será escolhido para o desenvolvimento deste sistema. Ter os meus dados armazenados em um banco de dados não-relacional também me deixou muito satisfeito.
Fiquei tão surpreso com o resultado que cheguei a pensar em abortar os outros testes. Mas aí a minha grande preocupação nasceu: enquanto as coisas estão funcionando conforme nos manuais tudo é maravilhoso. Mas e o dia que elas não funcionarem de acordo? Por essa razão julguei ser o momento de passar para a próxima tentativa: “TurboGears”.
O TurboGears
Eu acredito que tenha sido o momento que eu escolhi para testar o TurboGears que tenha feito eu me decepcionar muito com ele. O projeto está numa fase muito “agitada” onde uma versão nova está saindo, um livro novo está saindo, a documentação está sendo toda refeita, a documentação antiga está sendo jogada fora, o site está em reformas, a lista de discussões está atendendo à tudo isso e mais o suporte ao desenvolvimento… é o caos. Organizado… mas caos.
O projeto está passando por uma fase onde duas coisas estão misturadas: estabilização da API e decisão dos próximos passos. A API está estável, mas duas decisões relacionadas aos próximos passos podem trazer mudanças enormes no projeto.
Uma das decisões do pessoal do TurboGears é a de trocar o ORM SQLObject pelo SQLAlchemy. Eu mexi com o SQLAlchemy e recomendo. O SQLAlchemy apresenta uma grande robustez (devido aos testes automatizados que ele tem), a forma com que o projeto foi feito o tornou muito mais extensível que o SQLObject e a documentação dele é uma obra de arte.
O TurboGears já diz ter um bom suporte ao SQLAlchemy mas não confie nisso ainda:
- O TurboGears usa um esquema de ActiveMapper do SQLAlchemy que foi criado pelos próprios desenvolvedores do TurboGears. O ActiveMapper permite fazer o ORM de uma maneira muito parecida com a do SQLObject mas ele ainda tem uma série de deficiências.
- O mecanismo de Identity do TurboGears é extremamente dependente do mecanismo de ORM. Se o SQLAlchemy não está 100% no TurboGears o sistema de Identity também não está.
- CatWalk, Toolbox, Designer, … e qualquer outra ferramenta do TurboGears que use o SQLObject não funciona com o SA ainda.
A outra mudança é relacionada à linguagem de template Genshi que entra no lugar da linguagem Kid que deixará de ser padrão no TurboGears. Essa mudança tem menos impacto porque será possível usar as duas linguagens e uma se parece muito com a outra.
Depois de muita cabeçada conclui que ainda não dá pra usar o SA e então reiniciei meus testes usando o SQLObject mesmo.
A sorte do TurboGears é que ele é muito leve, fácil e descomplicado porque se eu fosse depender de documentação eu estaria perdido. A documentação do TurboGears sofre do mal da desorganização. Não falta documentação, mas ela está toda desencontrada, desatualizada, descentralizada, mal indexada, etc. A menos que você tenha saco de ficar assistindo um filminho (screencast) de 10 minutos para cada coisa que você queira aprender a fazer no TurboGears você irá sofrer.
Usando o código fonte e alguns exemplos (”Use the source Luke!“) eu consegui fazer uma parte considerável do teste com o TurboGears. Tive que brigar um pouco com o SQLObject mas isso aconteceu graças à minha ojeriza a bancos de dados relacionais. Odeio ter que pensar em minhas classes correntamente e depois sair serrando, picando e estripando para que elas caibam em tabelas.
Dos frameworks testados esse foi o que mais caiu em meu conceito porque você tem que lutar o tempo todo contra a documentação (isso inclui a documentação dos módulos de terceiro) e contra a falta de aplicações mais completas que sirvam de exemplo para aprender TurboGears.
A dica pros TurboGear-zeiros brasileiros que contribuem com este projeto é: mais atenção na documentação!
Django
Esse era o framework que eu menos conhecia e aparentemente ele é o favorito do Guido van Rossum. Também foi a minha maior surpresa (positiva) porque comecei a desenvolver os testes nele e quando vi tive que dar uma “pisada no freio” porque já estava quase terminando a aplicação toda. Tá, é um exagero. Mas é tão agradável desenvolver com o Django que me senti da mesma forma de quando comecei a programar em Python: feliz.
O tutorial do Django aberto no browser, o editor aberto no terminal, e código foi tudo o que precisei para o teste. Fui dormir às 4 da madrugada com uma sensação agradável de quem tinha se divertido programando.
O Django usa um ORM dele que é menos poderoso que o SQLAlchemy, mas é muito mais gostoso de usar do que o SQLObject. Ele também disponibiliza um monte de “tipos de dados” muito úteis como o FileField que permite criar campos com upload de arquivos e já informar em que diretório esse arquivo será armazenado (enquanto que no BD fica apenas o path para esse arquivo). Isso também não muda o fato de que o famigerado “banco-de-dados-jurássional” está ali.
A linguagem de template do Django também é feita pra ele. Funciona no mesmo esquema do PHP onde você coloca código Python no meio de tags HTML. Eu acho mais agradável fazer templates assim porque sou programador. Mas devo admitir que você tem que desenhar o template às cegas, já que não é possível ver esses templates no browser enquanto estamos desenhando (isso é possível com o Kid, Genshi, ZPT, … que funcionam com o TurboGears).
O sistema de mapeamento de URLs do Django é muito chato de configurar mas em pouco tempo você percebe que ele é extremamente poderoso. No TurboGears é muito mais simples lidar com isso porque você não tem o conceito de mapeamento mas eu não sei se essa forma de trabalhar não apresenta limitações (não consigo imaginar nenhuma limitação, mas talvez elas existam).
Considerações Finais
Vocês devem estar se perguntando: “E então, qual você escolheu?”. Eu ainda não escolhi. Tudo indica que o Django leva a taça. Mas os outros possuem algumas coisas que podem reverter esse quadro:
- Plone - eu tenho amigos extremamente qualificados em Plone. Uma conversa de poucos minutos com eles pode eliminar uma série de dúvidas técnicas que tenho e ele seja escolhido por ser, entre os três, o que apresentou a maior facilidade de desenvolver todo o sistema.
- TurboGears - Ainda tem a minha simpatia por ‘caber na minha cabeça’. O fator eu-posso-ajudar-nesse-projeto também pesa a favor dele porque é como os mazoquistas dizem: “Os maiores desafios trazem as maiores recompensas.”
- Django - vou afundar mais a minha cabeça neste projeto para ver como ele funciona e ver se o coração dele condiz com a cara que ele me apresentou.
Nota do autor: Escrevi esse artigo às pressas e não pude revisar. Se encontrarem erros ou tiverem alguma idéia ou sugestão coloque no comentário. Pretendo com isso melhorar esse artigo para disponibilizar no PythonBrasil.
Fundamentos do desenho orientado a objetos com UML (Fundamentals of Object-Oriented design in UML)
Postado por Osvaldo Santana
Como eu já havia comentado na minha resenha anterior (Padrões de Projeto) este livro foi fundamental para o meu entendimento sobre programação orientada à objetos. De todos os livros que considero leitura obrigatória este entrou na lista este entrou na lista mais por “gratidão aos serviços prestados” do que por ser um livro “matador”.
É bem provável que existam livros que tratam sobre o desenho orientado à objetos que são mais completos do que este mas esse me cativou pela forma como foi escrito. Ele é um livro que trata de assuntos realmente chatos e complicados de se explicar usando uma dose muito sutil de bom-humor.
Em um dos capítulos o autor, Meillir Page-Jones, lista uma série de erros comuns que são cometidos por programadores de primeira viagem e explica porque esses erros ocorrem. O exemplos citados por eles são bastante capciosos e em alguns casos a gente consegue perceber que estão errados mas não conseguimos imaginar como consertaríamos esses erros. Neste caso então ele nos acompanha passo a passo até a solução do problema listado.
Outros assuntos tratados de forma mais séria e profunda no livro são relacionados à idéia básica da POO que é desenvolver sistemas com:
- Alta coesão
- Baixo Acoplamento
Desenvolver componentes de software com alta coesão, baixo acoplamento e pensando em interfaces no lugar de tipos (como sugerido no livro Padrões de Projeto) certamente farão com que seus sistemas fiquem extremamente robustos. Se eles forem acompanhados de Testes automatizados (XP), refatorados constantemente (Refatoração) não consigo pensar em um adjetivo melhor do que “perfeito” para atribuir ao seu trabalho.
Eu li a versão traduzida para o português deste livro. A tradução foi feita pela editora Makron e achei a tradução razoável. Não é uma boa tradução mas a leitura e o entendimento do assunto não fica comprometida por causa dela. Me parece também que a versão traduzida saiu de circulação e por essa razão pode ser mais complicado achar a versão traduzida para comprar.
Para comprar: Fundamentos do desenho orientado a objetos com UML ou Fundamentals of Object-Oriented design in UML
Padrões de Projeto (Design Patterns)
Postado por Osvaldo Santana
Programo computadores há muito tempo. Quando iniciei minha ‘carreira’ usava a linguagem BASIC e LOGO em meu MSX Expert (BASIC) e um TK3000 (LOGO). A linguagem BASIC causou alguns estragos gigantescos em meu cérebro tornando superdifícil aprender a programar em uma linguagem estruturada futuramente. Foi difícil eu perder o meu apego ao “GOTO”.
Mas depois de ter lido um livro sobre Turbo Pascal, cujo nome do autor infelizmente não me recordo, todo o que eu já tinha visto sobre o paradigma procedural se encaixou magicamente e aquilo começou a fazer sentido pra mim. Eu gosto de chamar isso que aconteceu comigo de ‘iluminação’.
Então esse livro sobre Turbo Pascal me iluminou para que eu compreendesse o paradigma procedural.
Mas então os programadores gritaram: “Faça-se a OO” e a OO “se fez”. Lá fui eu novamente correr atrás de entender como essa tal de “Programação Orientada a Objetos” funcionava.
Li muita coisa. Vi muito hype em cima do assunto. Vi muita mágica sendo feita e muita mágica sendo desfeita usando-se POO. Mas aquilo ainda não fazia muito sentido pra mim.
Depois de ler um livro chamado “Fundamentos do Desenho Orientado a Objetos” (que falarei no futuro) o meu cérebro começou a criar as conexões entre todo o conhecimento que eu já tinha adquirido. Mas faltava a faísca para produzir o fogo que me iluminaria.
Com a popularização da linguagem Java vários hypes surgiram (e continuam a surgir) e entre eles estavam os “Design Patterns“. Nem dei muita atenção porque as ‘modinhas’ produzidas no universo javanista são tão duradouras quanto a fama que o grupo musical “Polegar” teve no passado.
Certo dia um livro chamado “Design Patterns” caiu em minhas mãos e resolvi folheá-lo. Notei que não tinha uma única linha de código em Java e então percebi que aquilo ali já existia antes mesmo de Java ter começado a lançar suas modinhas.
Comecei a ler o livro e em uma passagem encontrei uma frase que dizia algo parecido com: “No desenvolvimento Orientado à Objetos não desenvolva para tipos, desenvolva para interfaces.” e aí então a faísca foi lançada.
Devorei o livro rapidamente e adquiri uma cópia (uma tradução para o português que estava muito mais barata do que o original em inglês) e devorei o conteúdo em uma semana.
O livro tem alguns capítulos que introduzem o conceito de padrões, fala sobre o modelo MVC (Model-View-Controller) para separação dos componentes de uma aplicação e fala sobre alguns conceitos de OO que são bem interessantes. A partir daí temos os padrões que são catalogados de maneira a possibilitar uma rápida consulta.
Cada padrão acompanha uma descrição, um diagrama explicativo, os casos de uso, os casos onde não devemos usar tal padrão, o relacionamento desse padrão com outros e exemplos em Smalltalk e C++.
Esse livro não é adequado para pessoas que ainda não conhecem os conceitos básicos da Programação Orientada a Objetos pois ele assume que o leitor já conheça ao menos o básico sobre este assunto.
A cópia traduzida que eu tenho é editada pela Bookman e tem uma tradução excelente onde os nomes dos padrões são preservados na forma original em inglês.
Esse livro é um clássico da literatura técnica e algumas pessoas o chamam de “GoF” que é a abreviação para “Gang of Four“, uma alusão aos quatro renomados autores do livro: Erich Gamma, Richard Helm, Ralph Johnson e John Vlissides.
Para comprar: Padrões de Projeto ou Design Patterns
