Feliz 2009!

Faltam pouco menos de duas horas para o ano novo. Estou em casa reunido com minha família, mas passei aqui no computador para escrever.

Como devem ter percebido, este blog está bastante abandonado. Gostaria de levar mais a sério o ato de blogar, mas eu nem escrevo muito e nem divulgo muito este blog. Vamos ver se mudo isso em 2009.

Há mais ou menos um ano atrás, escrevi sobre minhas metas “nerds” para 2008. Vamos ver o que fiz e o que não fiz:

• Meta 1: aprender Hibernate – não aprendi da forma como gostaria, que seria lendo o livro Java Persistence With Hibernate. Acabei aprendendo na marra, mexendo nos sistemas do trabalho;
• Meta 2: aprender JSF – idem item anterior, com a diferença que não aprendi o suficiente pra desenvolver uma aplicação do zero. Não por preguiça, mas sim porque acabei conhecendo outros frameworks bem mais interessantes, como o Wicket;
• Meta 3: estudar design patterns – sim! Li (quase) todo o livro Head First Design Patterns. Recomendado;
• Meta 4: ler o livro de Martin Fowler sobre padrões arquiteturais – nem cheguei perto desse livro…
• Meta 5: estudar Test-Driven Development – acabei estudando TDD por tabela, quando estudei um pouco de XP. Mas não cheguei a por em prática;
• Meta 6: estudar Domain-Driven Design – sim! Estudei bastante esse assunto e tentei aplicá-lo o máximo que pude nos projetos da faculdade que desenvolvi. No trabalho, infelizmente não tenho a liberdade que gostaria para utilizá-lo;
• Meta 7: Ruby – sim! Estudei bastante Ruby esse ano, e cheguei a utilizá-lo em algumas tarefas importantes no trabalho.

O balanço foi bom, apesar de não ter feito tudo. E quais as metas nerds pra 2009?

• Terminar os cursos de JRuby On Rails e de JEE do site JavaPassion;
• Ler o livro de Domain Specific Languages de Martin Fowler, que está prestes a ser lançado;
• Aplicar Ruby On Rails em algum projeto;
• Estudar bastante metodologias ágeis (XP e Scrum);
• Aprofundar e fixar mais os conhecimentos em Ruby através da leitura do livro do Why (o original ou a tradução);
• Estudar REST
• E, se der tempo, cumprir as metas de 2008 pendentes

É isso! Feliz ano novo para todos nós!

OO em Delphi

A linguagem Delphi (a linguagem, não a ferramenta) tem muitos recursos interessantes, dentre eles total suporte à orientação a objetos. Porém, muitos programadores Delphi não os utilizam por desconhecimento. Percebo que o ensino em Delphi nas faculdades e cursos técnicos sempre foi bastante alienante, com foco na ferramenta, e não na linguagem.

Desde cedo somos habituados a arrastar componentes e programar eventos, sem sequer olharmos o código que a ferramenta gera, tampouco entendê-lo. E o pior é que isso é suficiente para programarmos sistemas completos na plataforma – não necessariamente com qualidade, claro. O resultado, muitas vezes, é um software difícil de manter, com mistura de código que trata de lógica de apresentação, negócios e persistência.

A partir de agora, pretendo escrever neste blog uma série de artigos ilustrando os recursos OO que a linguagem Delphi oferece, traçando um paralelo com outras linguagens (principalmente Java, mas quando conveniente, Ruby ou JavaScript). Não há um roteiro de publicação definido; os temas serão avulsos, abrangendo as mais variadas características de uma boa linguagem OO, como encapsulamento, polimorfismo, padrões de projeto, etc.

Para você que sempre programou em Delphi de maneira tradicional, esses conceitos poderão ser úteis para abrir sua mente, assim como abriram a minha.

Drawspace: curso on-line de desenho gratuito

Desenterrando este blog para uma notícia boa.

Há muito tempo atrás eu costumava desenhar, mas parei no tempo. Ultimamente venho pensando em voltar, então procurei no Google algum curso de desenho. Acabei achando este excelente site, que dispõe de mais de 300 lições devidamente categorizadas para Iniciante, Intermediário e Avançado.

Segue o link:

http://www.drawspace.com/

Enrolação de dependências – parte III

Finalmente, a parte final deste artigo!

Antes de prosseguir, leia: http://cabritin.wordpress.com/2008/03/07/enrolacao-de-dependencias-parte-ii/

Observe novamente a figura publicada na parte 1:

O diagrama ilustra uma relação um-para-muitos entre empresa e funcionário, este podendo ser um gerente ou um empregado.

Vamos traduzir este diagrama em um pouco de código. Inicialmente, poderíamos implementá-lo da seguinte maneira:

public class Empresa {
    private List<Funcionario> funcionarios;

    public Empresa() {
        funcionarios = new ArrayList<Funcionario>();
    }

    public void addGerente() {
        funcionarios.add(new Gerente()); // Linha 9
    }

    public void addEmpregado() {
        funcionarios.add(new Empregado()); // Linha 13
    }
}

public interface Funcionario {

}

public class Empregado implements Funcionario {
    // Construtores, atributos, métodos, etc
}

public class Gerente implements Funcionario {
    // Construtores, atributos, métodos, etc
}

Há algum problema nessa implementação? Aparentemente, não. Ela está bonitinha, usando polimorfismo, inversão de dependências (lembra o que é?) e tudo o mais. Mas veja só: a classe Empresa está instanciando diretamente as classes Gerente e Empregado (linhas numeradas). Tá, mas e qual o problema nisso? Ora, simples: se por acaso os construtores dessas classes mudarem, precisaremos modificar também as linhas 9 e 13. Agora, imagine se eu tivesse 50 classes, todas dependendo de Empregado e Gerente! Ia sobrar pro estagiário fazer a modificação em todas elas…

Mas vamos facilitar a vida do estagiário. Vamos tentar aplicar Inversão de Controle à situação.

O que queremos, então? Queremos evitar que Empresa instancie Empregado e Gerente diretamente; queremos diminuir o acoplamento entre as classes. A criação das instâncias é a responsabilidade que queremos inverter, ou seja, deixar para outra entidade fazê-lo.

Resumindo: a classe Empresa não mais criará as instâncias; ela as receberá já criadas. Como? Através dos métodos addEmpregado() e addGerente(). Vamos modificá-la então!

public class Empresa {
    private List<Funcionario> funcionarios;

    public Empresa() {
        funcionarios = new ArrayList<Funcionario>();
    }

    public void addFuncionario(Funcionario f) {
        funcionarios.add(f);
    }
}

Nossa! A classe Empresa ficou totalmente independente dos tipos concretos de Funcionario. Ela nem sabe mais que eles existem! O código cliente que utilizar as classes de domínio usará a classe como se segue:

Empresa e = new Empresa();
e.addFuncionario(new Gerente());
e.addFuncionario(new Empregado());

Ou seja, os funcionários são agora injetados dentro da empresa através do método addFuncionario(). Espere um pouco, você disse injetados?

Sim. Utilizamos um método que serve para passarmos para a (injetarmos na) classe Empresa as instâncias (dependências) de que ela precisa – neste caso, os funcionários de uma empresa. Invertemos o controle da instanciação dos objetos para o código cliente. Isto é injeção de dependências.

Há outras formas de injetar dependências em uma classe, como por exemplo fazê-lo por meio de um construtor (passando a dependência como argumento). E há também outras formas de instanciar os objetos de que sua aplicação precisa: frameworks como o Spring e o PicoContainer implementam containers que cuidam do processo de instanciação. Se não quiser utilizar um desses containers, um Factory Method resolve seu problema muito elegantemente.

Para encerrar, sugiro fortemente que você leia o artigo do Martin Fowler sobre o assunto. Estes posts não têm a intenção de substituí-lo: serve apenas para dar uma idéia geral.

Até mais.

Curso introdutório gratuito de Ruby On Rails

Deixem-me dar essa notícia antes que eu esqueça novamente

Lembram do curso gratuito de Ruby, ministrado pelo indiano Satish Talim? Um amigo dele resolveu seguir a onda, e abriu um curso de Ruby on Rails. Seu nome é Sunil Kelkar. O curso terá início no dia 12 de abril.

Tá esperando o quê? Matricule-se!

Enrolação de dependências – parte II

Antes de prosseguir, leia: http://cabritin.wordpress.com/2008/03/06/enrolacao-de-dependencias-parte-i/

Inversion of Control – IoC (inversão de controle)

Podemos definir inversão de controle como sendo simplesmente a transferência de uma ou mais responsabilidades para uma entidade exterior, que decidirá o momento e a ordem de ocorrência dos eventos inerentes a essas responsabilidades. Esse princípio já existe há muito tempo, e não se restringe somente ao mundo da computação.

Por exemplo, se você tem uma conta pra pagar, você se encaminha ao banco e paga. Ou seja, é sua responsabilidade controlar o evento “pagar minha conta”, e é você quem toma a decisão do momento em que deseja pagá-la. Porém, se você não tem tempo e pede para sua irmã efetuar o pagamento para você, você transferiu a responsabilidade sobre o evento “pagar minha conta” para ela. Assim, ela é quem vai tomar a decisão do momento de pagar a conta, lhe devolvendo o comprovante de pagamento.

Uma expressão famosa que ilustra a IoC é enunciada pelo princípio de Hollywood: “don’t call us, we call you”.

Dentro da computação, uma aplicação do conceito de inversão de controle pode ser encontrada em ferramentas baseadas em programação orientada a eventos, como o Delphi e o Visual Basic. Um programa orientado a eventos consiste, muito simploriamente, em um laço principal com duas seções: detecção e tratamento de eventos:

main()
    repita
        // Detecta eventos registrados pelo programador
        detecte_eventos()
        // Executa os eventos registrados
        trate_eventos()
    fim
fim

Quando desenvolvemos aplicações gráficas usando as IDEs referenciadas, utilizamos um framework de criação e gerenciamento de janelas e eventos (no Delphi para Win32, por exemplo, esse framework é o VCL, que significa Visual Component Library) , e esse framework fica responsável por executar o laço acima. Tudo o que precisamos fazer é definir os eventos em nosso programa e registrá-los; nós não somos mais responsáveis por executá-los. As IDEs fornecem inúmeros recursos para facilitar o registro desses eventos.

Note que, se implementarmos o laço por nós mesmos, não estamos invertendo controle de coisa alguma! Utilizar programação orientada a eventos não implica necessariamente em utilizar inversão de controle. Para isso, devemos usar alguma entidade externa – um framework, ou uma biblioteca – que execute o laço para nós e cuide das questões inerentes à detecção e tratamento de eventos.

Podemos encontrar outra aplicação de inversão de controle no paradigma orientado a objetos. Sim, estamos falando da injeção de dependências, um tipo de inversão de controle onde a responsabilidade a ser “invertida” é o processo de obter dependências. Será o tema da próxima parte deste artigo, onde retomaremos o exemplo desenvolvido na primeira.

Até lá.

Enrolação de dependências – parte I

Uma das metas que mais se busca em orientação a objetos é diminuir o acoplamento entre os componentes da aplicação (componentes aqui são classes, pacotes, camadas, etc). E uma das formas mais eficientes de se fazer isso é utilizando injeção de dependências. Mas como toda boa prática que se torna popular, ela não podia deixar de gerar confusão entre aqueles que tentam utilizá-la. E também não podiam deixar de aparecer os “entendidos no assunto”: vomitam as palavras sem nem saber o que é e para quê serve esse recurso.

As expressões que estão na boca do povo nem sempre são as mais adequadas. Muitos se referem à prática em questão como “inversão de dependências”. Depois aparece outro que tenta corrigir, dizendo que “inversão de dependências não existe”. E chega outro falando de uma tal de “inversão de controle”. No final das contas, muitos acabam achando que as três expressões são sinônimas.

Pois bem. Vamos tentar desmistificar as coisas!

Inversão de dependências

Vamos supor que estamos desenvolvendo um sistema de cadastro de funcionários de uma empresa, onde os funcionários podem ser de dois tipos: gerentes e empregados.

Tentaremos uma primeira abordagem, ilustrada pelo diagrama de classes abaixo. De acordo com ele, uma empresa possui um ou mais gerentes e um ou mais empregados.

Na figura, podemos verificar que a classe Empresa depende claramente de classes concretas, que são Gerente e Empregado. Ou seja, sempre que quisermos uma instância de Gerente na classe Empresa, teremos que obtê-la usando new Gerente(). Isso tem um lado ruim, pois se essas classes mudarem a forma como são instanciadas (modificações nos parâmetros dos construtores, por exemplo), teremos fatalmente que mexer no código da classe Empresa. Sem falar nas alterações decorrentes de um novo tipo de funcionário sendo adicionado.

Diante deste cenário, vamos enunciar o princípio da inversão de dependências:

“Componentes de alto nível não devem depender de componentes de baixo nível. Ambos devem depender de abstrações.”

Componentes de alto nível são assim chamados porque seu comportamento depende de outros componentes, os de baixo nível. No diagrama acima, Empresa é um componente de alto nível, enquanto Gerente e Empregado são de baixo nível.

E agora, como aplicar esse princípio ao diagrama acima? Simples. Posicione uma abstração entre os componentes de alto nível e os de baixo nível. Assim, ambos dependerão de abstrações:

E pronto! O princípio da inversão de dependências está aplicado. Mas qual a vantagem? Uma delas é que, a partir de agora, a classe Empresa não conhece nada sobre as implementações de Funcionario; sabe apenas que lida com funcionários, não importando se são gerentes ou não. Ou seja, desacoplamento.

Mas ainda temos um problema. Antes, quando Empresa dependia de funcionários concretos, eu os instanciava diretamente usando o operador new. E agora? A inclusão dessa interface não retirou o meu problema; eu ainda preciso instanciar os funcionários usando new. E isso significa dizer que as classes ainda estão acopladas!

Ahhhhhhhh, garotinho… É exatamente nesse ponto que entra a Injeção de Dependências. Nós não criaremos as instâncias; alguém as criará para nós. Mas isso é assunto para a segunda parte desse artigo.

Até lá.

Grails – bug na versão 1.0

O Grails tem um comando chamado “generate-all”, cuja finalidade é gerar o código-fonte das classes de controle e de visão. O comando executa o script “GRAILS_HOME/scripts/GenerateAll.groovy” para realizar essa tarefa (GRAILS_HOME representa o local onde o Grails está instalado).

Entretanto, o script contido na versão 1.0 do Grails apresenta um erro na linha 53, que gera a seguinte mensagem:

Error executing script GenerateAll: startup failed, GenerateAll_groovy: 53: you
tried to assign a value to the class ‘resources’. Do you have a script with this
name?
@ line 53, column 4.
1 error

Para corrigir este erro, basta abrir o script e modificar a linha 53, adicionando “this.” (sem as aspas) na frente da variável “resources”.

Mais informações em http://www.guj.com.br/posts/list/82619.java.

Desenvolvimento ágil DE VERDADE com Grails

Groovy é uma linguagem de programação orientada a objetos desenvolvida para a plataforma Java, que possui recursos de Python, Ruby e Smalltalk. Está em processo de padronização através da JSR 241.

Grails, abreviação de Groovy on Rails, é um framework para desenvolvimento web com a linguagem Groovy que traz as características do Ruby on Rails para a plataforma (e não a linguagem) Java. Sua intenção é fornecer alta produtividade se baseando no paradigma “coding by convention”, escondendo muitos detalhes de implementação do desenvolvedor.

Baixei, instalei e fiz testes com o Grails, e fiquei surpreso com a produtividade do bichinho. O desenvolvedor fica realmente livre para se preocupar com aquilo que a aplicação possui de maior importância: regras de negócio. Eu poderia escrever um artigo ou um “Hello World with Grails” para este blog, mas vou simplesmente passar um link para um livro com cerca de 100 páginas – e gratuito – que é bastante agradável de ler. Ele introduz as características do framework aos poucos.

Observação: É preciso se registrar no site para obter o livro.

É… A comunidade Java há muito já se rendeu ao Python e ao Ruby, e está percebendo que há maneiras MUITO mais simples de construir coisas simples.

Testando o JRuby

Hoje baixei e instalei o JRuby, uma implementação 100% Java da linguagem Ruby. Já faz tempo que tenho vontade de testar, pois a possibilidade de utilizar a API Java na linguagem Ruby me atrai bastante.

Baixei a versão 1.0.3, descompactei, configurei a variável PATH para apontar para o subdiretório bin e… Voilá! Pronto para usar na linha de comando!

Então escrevi o seguinte programa:

require 'java'
include_class 'javax.swing.JFrame'

class FrameTeste
  def initialize
    @frame = JFrame.new("Teste do JRuby")
    @frame.setSize(300, 300)
    @frame.setLocationRelativeTo(nil)
    @frame.setDefaultCloseOperation(
      JFrame::DISPOSE_ON_CLOSE)
  end

  def show
    @frame.setVisible(true)
  end
end

f = FrameTeste.new
f.show

Salvei em um arquivo “frame_teste.rb”, e então executei utilizando o seguinte comando:

jruby frame_teste.rb

E o JRuby exibiu na tela uma janela em Swing. Muito legal! Imaginem só, unir o poder das duas linguagens! As possibilidades são enormes. Pode-se até mesmo rodar uma aplicação desenvolvida no Ruby on Rails!

Pra quem programa em Java e está estudando Ruby, é imprescindível conhecer essa ferramenta. Vou passar os próximos dias brincando com ela