Desenvolvimento de software e tecnologia em geral
Artigos com o marcador Livro
Self-Service Design Patterns
10/09/09
O título desse post realmente é estranho, mas calma, não estou criando um novo catálogo de padrões de projetos baseado na culinária brasileira.
Na verdade é somente um desabafo para que nós (desenvolvedores de software) não utilizemos Design Patterns sem motivo em nossos projetos.
Depois de um bom tempo trabalhando com desenvolvimento de software e de ter passado por inúmeros projetos, vejo que muitas vezes as arquiteturas dos softwares desenvolvidos contém vários Design Patterns que nem sempre são necessários para o bom design do projeto, adicionando camadas (layers) desnecessárias ao projeto e tornando o desenvolvimento e manutenção mais trabalhosa e difícil.
Costumo ver muito arquiteturas do tipo Action->Facade->Service->DAO, que mais parece ser uma receita de bolo. Não que um software desenvolvido nessa arquitetura esteja errado ou certo, mas o meu principal questionamento é a real necessidade de ter implementado estes ou aqueles padrões de projetos.
Conforme descrição no Wikipedia:
Design Patterns, descrevem soluções para problemas recorrentes no desenvolvimento de sistemas de software orientados a objetos. Um padrão de projeto estabelece um nome e define o problema, a solução, quando aplicar esta solução e suas conseqüências.
Na descrição acima vemos que os padrões de projetos existem para resolver certos problemas em uma arquitetura de software orientado a objetos e não para serem utilizados “á vontade” (self-service), mas infelizmente hoje vejo muitos desenvolvedores aplicando Design Patterns nos projetos apenas para poder dizer ( para outros ou para si mesmo ) que usa o Design Pattern XPTO no seu projeto e/ou que já possui experiência com Design Patterns. Com atitudes assim perde-se 2 vezes, uma no conhecimento pois o desenvolvedor está aprendendo de maneira errada a usar determinado padrão de projeto, e outra perde-se também na qualidade do software desenvolvido.
Um dos padrões que sofre com esse problema hoje é o Facade, pois sempre que vejo algo do tipo:
public class XptoFacade{
private XptoService xptoService;
public void insert( Xpto o ) {
xptoService.insert( o );
}
public void update( Xpto o ) {
xptoService.update( o );
}
public void delete( Xpto o ) {
xptoService.delete( o );
}
public void update( Object o ) {
xptoService.update( o );
}
public List<Xpto> list() {
return xptoService.list();
}
}
Me pergunto se este Facade realmente é nessário ja que ele serve apenas para replicar as chamadas de um único Service e sempre me lembro de uma parte do livro Pojos in Action, onde o autor fala um pouco sobre Exposed Domain Model, mostrando os prós e contras de um modelo de domínio exposto e de um que utiliza o padrão Facade.
Então para não prolongar muito o post deixo uma dica que considero muito importante:
Antes de aplicar um Design Pattern no seu projeto, se informe bastante sobre o padrão, veja se o problema que o padrão se propõe a resolver condiz com o problema que você espera solucionar ao aplicá-lo em seu projeto e lembre-se que uma boa arquitetura necessariamente não é aquela que aplica todos os padrões do GoF ou do POEAA.
Aprendendo Rails com o livro do Urubatan
28/04/09
Semana passada dei uma passada rapida em uma livraria apenas para dar uma olhada nos livros de TI. Como estou pensando em desenvolver um projeto pessoal novo, passei um curto periodo analisando quais tecnologias utilizar no projeto e acabei decidindo que iria utilizar Ruby on Rails (Me perdoe Java!
).
Embora eu já tenha codificado um pouco em Ruby, ainda conheco muito pouco de Rails. Então além de pegar varios materiais na internet, também decidi comprar um livro para acelerar o aprendizado.

Ruby on Rails | Desenvolvimento Fácil e Rápido de Aplicações Web
Encontrei cerca de cinco títulos na livraria que fui e dos cinco, quatro eram baseados no Rails 1.2. O unico que utilizava a versão mais nova do Rails era o livro do Rodrigo Urubatan – Ruby on Rails | Desenvolvimento Fácil e Rápido de Aplicações Web que por esses e outros fatores (ser um livro bem prático, nada de tradução mal feita e etc), acabei optando por ele.
Já comecei a ler o livro e estou gostando bastante, assim que terminar a leitura eu crio um novo post com mais detalhes sobre o livro e quem sabe em breve terei um novo projeto em RoR rodando por aí.
Livro Pojos in Action
14/10/08
Rescentemente terminei a leitura do livro Pojos In Action de Chris Richardson, embora este livro seja de 2006 e utilize em seus exemplos versões antigas de frameworks como Spring 1.23, Hibernate 3.0 e EJB3 (Beta), não consigo deixar de recomendá-lo.
Pois é um ótimo livro para quem procura exemplos de como utilizar estes e alguns outros frameworks, assim como aplicar Test-driven Development (TDD) e alguns patterns no domain model.
Uns dos pontos que mais gostei no livro é a sua explicação sobre domain model, onde ele explica e exemplifica o pattern Facade, Exposed Domain Model e seus prós e contras ao aplicá-los.
Inclusive em muitos pontos do livro pode-se ver referências a padrões explicados no livro Patterns Of Enterprise Application Archittecture de Martin Fowler, na qual já comprei mais ainda não li e assim que concluir a sua leitura, irei dedicar um post exclusivo para este livro.
Últimos comentários