Arquivo

Textos com Etiquetas ‘Design Patterns’

2010 em livros

5 de janeiro de 2011

Estou a “plagiando” uma idéia de Phillip Calçado que fez um post em seu blog mostrando os livros lidos no ano de 2010, com um pequeno comentário sobre cada um.

Com certeza minha lista é muito mais modesta e curta, mas a idéia de compartilhar conhecimento é a mesma.

Esse post também serve para me alertar a ler mais, mesmo com toda a correria de trabalho, família, estudo e prática de esportes, gostaria de ter lido mais que 7 livros durante 2010.

Os livros são apresentados na ordem que foram lidos:

Clean Code: A Handbook of Agile Software Craftsmanship

Clean Code: A Handbook of Agile Software Craftsmanship

Robert C. Martin
Prentice Hall
August 2008

Muito bom

Todo programador deveria ler. Uncle Bob nos concede um pouco de sua vasta experiência em desenvolvimento de software, mostrando como deixar seu código mais enxuto, legível e simples. Esse livro serviu de inspiração para várias palestras e apresentações por aí sobre como escrever código de melhor qualidade.

The RSpec Book: Behaviour-Driven Development with RSpec, Cucumber, and Friends

The RSpec Book: Behaviour-Driven Development with RSpec, Cucumber, and Friends

David Chelimsky, Dave Astels, Zach Dennis, Aslak Hellesøy, Bryan Helmkamp, Dan North
The Pragmatic Programmers
December 2010

Ótimo

Essencial para quem quer aprender RSpec. Explica como seria o ciclo ideal de BDD. Também traz exemplos práticos de utilização de RSpec e Cucumber com Ruby e Ruby on Rails.

JavaScript: The Good Parts

JavaScript: The Good Parts

Douglas Crockford
O’Reilly
May 2008

Muito bom

Quem curte JavaScript irá gostar bastante. Fiz anotações sobre esse livro nesse post.

Design Patterns in Ruby

Design Patterns in Ruby

Russ Olsen
Addison-Wesley Professional
December 2007

Bom

Traz uma boa parte dos design patterns apresentados pela GoF utilizando Ruby. O que eu achei mais interessante foi a abordagem utilizada pelo autor: dado um design pattern, o mesmo é implementado de uma maneira clássica e depois reimplementado usando os recursos que o Ruby oferece, como por exemplo, metaprogramação, tornando alguns patterns totalmente diferentes de sua implementação original.

Professional ASP.NET MVC 2

Professional ASP.NET MVC 2

Jon Galloway, Scott Hanselman, Phil Haack, Scott Guthrie, Rob Conery
Wrox
June 2010

Muito bom

Sempre gostei da séria Professional da Wrox e esse livro mantém a linha de qualidade. Logo no primeiro capítulo tem um passo a passo da construção de uma pequena, mas completa, aplicação ASP.NET MVC 2. Os demais capítulos cobrem os demais recursos do framework. Só pelos autores já vale a leitura.

ASP.NET MVC 2 in Action

ASP.NET MVC 2 in Action

Jeffrey Palermo, Ben Scheirman, Jimmy Bogard, Eric Hexter, Matthew Hinze
Manning
June 2010

Regular

Talvez se eu não tivesse lido o livro da Wrox antes teria classificado melhor este. Em algumas vezes os autores focam demais no uso de ferramentas extras, auxiliares ao desenvolvimento de aplicações ASP.NET MVC 2. Isso é bom para quando você já tem conhecimento e/ou vivência do framework.

Test-Drive ASP.NET MVC

Test-Drive ASP.NET MVC

Jonathan McCracken
The Pragmatic Programmers
June 2010

Regular

Eu esperava bem mais desse livro por se tratar de TDD. Havia imaginado vários passos práticos de desenvolvimento orientado a testes no melhor estilo Kent Beck ou Uncle Bob. Para quem já conhece TDD, não irá ver grandes novidades.

Eu uso o Shelfari como prateleira virtual para organizar os livros que li, estou lendo e pretendo ler.
É bem legal e tem vários recursos. Por exemplo, esse endereço lista os livros que li no ano de 2010.

.NET, Arquitetura, JavaScript, Livros, Ruby, TDD , , , , , , , , , , , ,

Múltiplos construtores em Ruby (minha versão)

10 de setembro de 2010

Ontem, através de uma mensagem no Twitter do André Moreira, estava lendo um post no blog do Rinaldi Fonseca falando sobre múltiplos construtores em Ruby. Comecei a escrever um comentário, que acabou se tornando muito grande. Então achei melhor escrever aqui para expressar minha opinião a respeito.

Na primeira parte do post é mostrado a utilização de métodos de classe para construir um novo objeto passando parâmetros diferentes dos recebidos no construtor, onde foi usado esse exemplo:

class Carro
  attr_accessor :marca, :placa, :dono

  def initialize(marca, placa, dono)
    @marca, @placa, @dono =  marca, placa, dono
  end

  def Carro.carro_sem_dono(marca, placa)
    new marca, placa, "SEM DONO"
  end

  def Carro.carro_sem_placa(marca, dono)
    new marca, "SEM PLACA", dono
  end
end

carro = Carro.new "Ferrari", "ABC1234", "João"
carro_sem_dono  = Carro.carro_sem_dono "Vectra", "ABC5678"
carro_sem_placa = Carro.carro_sem_placa "Palio", "José"

puts carro.inspect           #<Carro: @dono="João", @placa="ABC1234", @marca="Ferrari">
puts carro_sem_dono.inspect  #<Carro: @dono="SEM DONO", @placa="ABC5678", @marca="Vectra">
puts carro_sem_placa.inspect #<Carro: @dono="José", @placa="SEM PLACA", @marca="Palio">

Os métodos carro_sem_dono e carro_sem_placa seguem o Factory Method Design Pattern (Padrão de Projeto Método Fábrica) e atuam como uma DSL na classe Carro. Desse modo, não há necessidade da redundância do nome da classe no ínicio de cada método fábrica:

class Carro
  attr_accessor :marca, :placa, :dono

  def initialize(marca, placa, dono)
    @marca, @placa, @dono =  marca, placa, dono
  end

  def self.sem_dono(marca, placa)
    new marca, placa, "SEM DONO"
  end

  def self.sem_placa(marca, dono)
    new marca, "SEM PLACA", dono
  end
end

carro = Carro.new "Ferrari", "ABC1234", "João"
carro_sem_dono  = Carro.sem_dono "Vectra", "ABC5678"
carro_sem_placa = Carro.sem_placa "Palio", "José"

puts carro.inspect           #<Carro: @dono="João", @placa="ABC1234", @marca="Ferrari">
puts carro_sem_dono.inspect  #<Carro: @dono="SEM DONO", @placa="ABC5678", @marca="Vectra">
puts carro_sem_placa.inspect #<Carro: @dono="José", @placa="SEM PLACA", @marca="Palio">

Já na segunda parte do post é mostrada uma maneira de se passar um bloco para o construtor da classe Carro e assim inicializar seus atributos:

class Carro
  attr_accessor :ano, :marca, :modelo, :dono, :cor, :tipo

  def initialize(&block)
    instance_eval &block
  end
end

carro = Carro.new do
  self.ano    = "2000"
  self.marca  = "Gol"
  self.modelo = "Exemplo"
  self.dono   = "Dono exemplo"
  self.cor    = "Vermelho"
  self.tipo   = "Tipo exemplo"
end

puts carro.inspect #<Carro: @ano="2000", @marca="Gol", @modelo="Exemplo", @dono="Dono exemplo", @cor="Vermelho", @tipo="Tipo exemplo">

Eu particularmente gosto do tipo de inicialização de atributos de um novo objeto permitada nas classes da camada Model de Ruby on Rails. O método new dessas classes (que herdam de ActiveRecord::Base) podem receber tanto um hash quanto um bloco com os valores dos atributos. Dessa maneira, a classe Carro poderia ser inicializada assim:

carro = Carro.new :ano => "2000",
                   :marca => "Gol",
                   :modelo => "Exemplo",
                   :dono => "Dono exemplo",
                   :cor => "Vermelho",
                   :tipo => "Tipo exemplo"

#ArgumentError: wrong number of arguments (1 for 0)

Eu disse poderia. Não pode, pois o construtor new espera um bloco e não um hash, e Carro não é uma classe Model do Rails.

Para solucionar isso, podemos modificar o construtor da classe Carro para receber um hash de atributos ao invés de um bloco. Então atribuímos cada valor presente no hash para seu respectivo atributo:

class Carro
  attr_accessor :ano, :marca, :modelo, :dono, :cor, :tipo

  def initialize(attributes = nil)
    attributes.each do |attr, value|
      self.send("#{attr}=", value)
    end unless attributes.nil?
  end
end

carro = Carro.new :ano => "2000",
                   :marca => "Gol",
                   :modelo => "Exemplo",
                   :dono => "Dono exemplo",
                   :cor => "Vermelho",
                   :tipo => "Tipo exemplo"

puts carro.inspect #<Carro: @ano="2000", @marca="Gol", @modelo="Exemplo", @dono="Dono exemplo", @cor="Vermelho", @tipo="Tipo exemplo">

Mas e se quisermos também ter a opção de inicializar a classe Carro passando um bloco? Sem problemas, usamos o comando yield passando como parâmetro self se um bloco foi fornecido:

class Carro
  attr_accessor :ano, :marca, :modelo, :dono, :cor, :tipo

  def initialize(attributes = nil)
    attributes.each do |attr, value|
      self.send("#{attr}=", value)
    end unless attributes.nil?

    yield self if block_given?
  end
end

carro = Carro.new do |c|
  c.ano    = "2000"
  c.marca  = "Gol"
  c.modelo = "Exemplo"
  c.dono   = "Dono exemplo"
  c.cor    = "Vermelho"
  c.tipo   = "Tipo exemplo"
end

puts carro.inspect #<Carro: @ano="2000", @marca="Gol", @modelo="Exemplo", @dono="Dono exemplo", @cor="Vermelho", @tipo="Tipo exemplo">

Nessa implementação sempre irá prevalecer o que vier no bloco. Então se você passar um hash e um bloco para o construtor ao mesmo tempo (o que é uma bizarrice), os atributos que coincidirem terão o valor que foi passado no bloco:

carro = Carro.new(:ano => "2000", :marca => "Gol", :modelo => "Exemplo") do |c|
  c.modelo = "MODELO DO BLOCO"
  c.dono   = "Dono exemplo"
  c.cor    = "Vermelho"
  c.tipo   = "Tipo exemplo"
end

puts carro.inspect #<Carro: @ano="2000", @marca="Gol", @modelo="MODELO DO BLOCO", @dono="Dono exemplo", @cor="Vermelho", @tipo="Tipo exemplo">

Esses eram meus comentários sobre o interessante assunto de construtores em Ruby.

Ruby , , , , , , ,

Cheeseburgers, Ruby e magia negra

19 de setembro de 2009

Vamos usar um pouco de magia negra do Ruby para encontrar uma alternativa à implementação clássica do Design Pattern Decorator apresentado pela GoF.

Imagem original de MarketFare Foods, Inc.

Imagem original de MarketFare Foods, Inc.

.
Este post é a continuação de dois anteriores:

Se você ainda não os leu, recomendo que o faça para entender o contexto do exemplo onde estamos aplicando o Design Pattern Decorator. O ponto onde paramos no último post foi o meu descontentamento em decorar um objeto Cheeseburger de uma forma não muito intuitiva.

Leia mais…

Arquitetura, Ruby , , , , , ,

Cheeseburgers, Decorators e Ruby

13 de setembro de 2009

No post Cheeseburgers, Decorators e Mocks eu mostrei um exemplo prático de utilização do Design Pattern Decorator, que começa com um design usando herança, desaclopa usando composição e finalmente aplica Decorator. Tudo isso foi feito em .NET com C#. Agora vamos fazer o mesmo exemplo de Decorator Pattern utilizando Ruby. Para entender melhor o contexto do exemplo utilizado, sugiro que você leia antes o post anterior.

Imagem original de MarketFare Foods, Inc.

Imagem original de MarketFare Foods, Inc.

Além de Ruby, utilizarei o RSpec como ferramenta de testes unitários. No final do post há os links para baixar o código completo.

Leia mais…

Arquitetura, Ruby , , , , , , , ,

Cheeseburgers, Decorators e Mocks

29 de julho de 2009

Em São Paulo, eu sempre comi cheeseburgers feitos com pão, hamburguer e queijo. Mas quando eu fui para Itararé, cidade do interior do estado de São Paulo, descobri que eles também colocavam milho no sanduíche.

Para exemplificar, vamos imaginar que o cheeseburger de Ilhéus-BA, venha com molho de pimenta. Só para constar, eu nunca fui para Ilhéus, apesar de ser a cidade natal de meu pai. Então na verdade não tenho a mínima idéia de como seja o cheeseburger de lá.

Imagem original de MarketFare Foods, Inc.

Imagem original de MarketFare Foods, Inc.

Vamos transportar esses três tipos de cheeseburgers para objetos e fazer alguns testes com eles. Usarei como plataforma .NET, linguagem C#, a ferramenta de testes unitários que vem com o Visual Studio 2008 e o Rhino Mocks como framework de criação de mocks.

Leia mais…

.NET, Arquitetura , , , , , , , , , , , , ,