Comentários sobre: Design Patterns: um mau sinal? http://blog.caelum.com.br/design-patterns-um-mau-sinal/ blog dos desenvolvedores da Caelum Wed, 16 May 2012 20:16:36 +0000 hourly 1 http://wordpress.org/?v=3.3.2 Por: Paulo Silveira http://blog.caelum.com.br/design-patterns-um-mau-sinal/comment-page-1/#comment-45557 Paulo Silveira Mon, 28 Jul 2008 22:50:01 +0000 http://blog.caelum.com.br/2006/12/17/design-patterns-um-mau-sinal/#comment-45557 Ola Marcio. De maneira alguma, o adapter foi muito bem aplicado nesse caso... Esse post só eta dando um alerta: muitas pessoas tentam encaixar um design pattern onde nao precisa, apenas pela questao de "usei um design pattern". tambem quero mostrar que muitos deles hoje em dia ja podem ser anti patterns, e nao representar mais boas praticas, dada a evolucao da linguagem, frameworks e tecnolgoia Ola Marcio. De maneira alguma, o adapter foi muito bem aplicado nesse caso…
Esse post só eta dando um alerta: muitas pessoas tentam encaixar um design pattern onde nao precisa, apenas pela questao de “usei um design pattern”. tambem quero mostrar que muitos deles hoje em dia ja podem ser anti patterns, e nao representar mais boas praticas, dada a evolucao da linguagem, frameworks e tecnolgoia

]]> Por: Marcio Muzzi http://blog.caelum.com.br/design-patterns-um-mau-sinal/comment-page-1/#comment-45555 Marcio Muzzi Mon, 28 Jul 2008 22:29:56 +0000 http://blog.caelum.com.br/2006/12/17/design-patterns-um-mau-sinal/#comment-45555 Olá Paulo, antes de tudo parabéns pelo artigo! Gostaria que você compartilhasse sua opinião sobre um problema que passei na prática. Num sistema, construído em PHP, onde dei manutenção evolutiva por alguns meses, havia cerca 30 classes de acesso a banco (alocadas no pacote dao). Todas as classes dao utilizavam uma instância da AdoDb (http://adodb.sourceforge.net). Surgiu a necessidade de substituir a AdoDb pela PDO (www.php.net/pdo). A primeira solução, logo descartada, era de alterar todas as 30 classes dao para utilizarem os métodos da PDO. A segunda solução, proposta por mim, foi utilizar o padrão Adapter. Criamos uma classe chamada "PdoAdapter" contendo métodos com assinaturas idênticas às da classe AdoDb. As classes dao passaram a utilizar a classe adaptadora, dispensando assim qualquer alteração nelas. Neste caso, segui exatamente o que os fãs dos padrões de projeto defendem, e que aparentemente foi a melhor solução, concorda? Você recomendaria outra solução melhor ao invés de utilizar um design pattern? Olá Paulo, antes de tudo parabéns pelo artigo!

Gostaria que você compartilhasse sua opinião sobre um problema que passei na prática. Num sistema, construído em PHP, onde dei manutenção evolutiva por alguns meses, havia cerca 30 classes de acesso a banco (alocadas no pacote dao).

Todas as classes dao utilizavam uma instância da AdoDb (http://adodb.sourceforge.net). Surgiu a necessidade de substituir a AdoDb pela PDO (www.php.net/pdo).

A primeira solução, logo descartada, era de alterar todas as 30 classes dao para utilizarem os métodos da PDO. A segunda solução, proposta por mim, foi utilizar o padrão Adapter.

Criamos uma classe chamada “PdoAdapter” contendo métodos com assinaturas idênticas às da classe AdoDb. As classes dao passaram a utilizar a classe adaptadora, dispensando assim qualquer alteração nelas.

Neste caso, segui exatamente o que os fãs dos padrões de projeto defendem, e que aparentemente foi a melhor solução, concorda? Você recomendaria outra solução melhor ao invés de utilizar um design pattern?

]]> Por: Dias http://blog.caelum.com.br/design-patterns-um-mau-sinal/comment-page-1/#comment-1423 Dias Wed, 03 Jan 2007 12:11:41 +0000 http://blog.caelum.com.br/2006/12/17/design-patterns-um-mau-sinal/#comment-1423 Opa! Uma duvida sobre o Value Object... se é necessário retornar do POJO para o controller ou uma view qualquer uma entidade e mais algum objeto ou variáveis, qual seria a alternativa sem um VO ou DTO, como queira. Parabens pelo Blog, ótimos posts. Abraço Opa! Uma duvida sobre o Value Object… se é necessário retornar do POJO para o controller ou uma view qualquer uma entidade e mais algum objeto ou variáveis, qual seria a alternativa sem um VO ou DTO, como queira.

Parabens pelo Blog, ótimos posts.

Abraço

]]> Por: João Paulo (neófito) http://blog.caelum.com.br/design-patterns-um-mau-sinal/comment-page-1/#comment-1184 João Paulo (neófito) Thu, 21 Dec 2006 15:57:52 +0000 http://blog.caelum.com.br/2006/12/17/design-patterns-um-mau-sinal/#comment-1184 Desculpem o erro. O livro ao qual eu me refiro é o Applying UML and Patterns, 3rd Edition, do Craig Larman. Desculpem o erro. O livro ao qual eu me refiro é o Applying UML and Patterns, 3rd Edition, do Craig Larman.

]]> Por: João Paulo (neófito) http://blog.caelum.com.br/design-patterns-um-mau-sinal/comment-page-1/#comment-1182 João Paulo (neófito) Thu, 21 Dec 2006 15:53:55 +0000 http://blog.caelum.com.br/2006/12/17/design-patterns-um-mau-sinal/#comment-1182 O livro citado é muito bom e didático. O problema é que "design" é diferente de "design patterns". Design são as bases de projeto de software OO, e design patterns são soluções de design comprovadas. Antes de se aprender patterns, deve-se aprender design. É nisso que consiste o erro da maioria dos desenvolvedores que aprendem patterns hoje em dia. O passo "aprender design" é pulado, esquecido. Outro ponto é a necessidade do uso dos patterns. Abstração tem um custo, e deve ser usada somente quando necessária. Para aprender design antes dos patterns propriamente ditos, recomendo o livro <a href="Applying UML and Patterns" title="http://www.amazon.com/Applying-UML-Patterns-Introduction-Object-Oriented/dp/0131489062/sr=1-1/qid=1166709562/ref=pd_bbs_sr_1/102-9216610-3889732?ie=UTF8&s=books" rel="nofollow">, do Craig Larman, que é uma introdução ao projeto de software OO. Lá ele destaca a nessecidade de saber quando e por que usar patterns. O livro citado é muito bom e didático. O problema é que “design” é diferente de “design patterns”. Design são as bases de projeto de software OO, e design patterns são soluções de design comprovadas. Antes de se aprender patterns, deve-se aprender design. É nisso que consiste o erro da maioria dos desenvolvedores que aprendem patterns hoje em dia. O passo “aprender design” é pulado, esquecido. Outro ponto é a necessidade do uso dos patterns. Abstração tem um custo, e deve ser usada somente quando necessária.

Para aprender design antes dos patterns propriamente ditos, recomendo o livro , do Craig Larman, que é uma introdução ao projeto de software OO. Lá ele destaca a nessecidade de saber quando e por que usar patterns.

]]> Por: Paulo Silveira http://blog.caelum.com.br/design-patterns-um-mau-sinal/comment-page-1/#comment-1105 Paulo Silveira Wed, 20 Dec 2006 17:24:14 +0000 http://blog.caelum.com.br/2006/12/17/design-patterns-um-mau-sinal/#comment-1105 Achei um link interessante sobre singleton: http://steve.yegge.googlepages.com/singleton-considered-stupid Achei um link interessante sobre singleton:
http://steve.yegge.googlepages.com/singleton-considered-stupid

]]> Por: Cameron Smith http://blog.caelum.com.br/design-patterns-um-mau-sinal/comment-page-1/#comment-1098 Cameron Smith Wed, 20 Dec 2006 10:31:55 +0000 http://blog.caelum.com.br/2006/12/17/design-patterns-um-mau-sinal/#comment-1098 Oi Paulo e Marcos. Um post interessante. Só para dar mais uma indicação da maneira que "Design Patterns" são ganhando "mindshare", enquanto deixam para trás qualquer noção da necessidade de /desenhar e ENTENDER/ seu programa, vejam esse livro, que analisei da última vez que tava no U.K.: http://www.amazon.co.uk/gp/product/0596007124 Em termos pedagógicos, o livro é de alta qualidade: tem diagramas, exemplos, exercícios, uma maneira de explicar bem clara etc. Só que: em qual momento você vai contratar um programador que pensa que "design" é copiar as receitas deste livro e implenta-los, com passos de bebé, no sistema? Além disso, a loirinha na capa não tem nada a ver com o livro!!! Oi Paulo e Marcos. Um post interessante. Só para dar mais uma indicação da maneira que “Design Patterns” são ganhando “mindshare”, enquanto deixam para trás qualquer noção da necessidade de /desenhar e ENTENDER/ seu programa, vejam esse livro, que analisei da última vez que tava no U.K.: http://www.amazon.co.uk/gp/product/0596007124

Em termos pedagógicos, o livro é de alta qualidade: tem diagramas, exemplos, exercícios, uma maneira de explicar bem clara etc. Só que: em qual momento você vai contratar um programador que pensa que “design” é copiar as receitas deste livro e implenta-los, com passos de bebé, no sistema?

Além disso, a loirinha na capa não tem nada a ver com o livro!!!

]]> Por: Marcos de Sousa http://blog.caelum.com.br/design-patterns-um-mau-sinal/comment-page-1/#comment-1059 Marcos de Sousa Tue, 19 Dec 2006 22:16:16 +0000 http://blog.caelum.com.br/2006/12/17/design-patterns-um-mau-sinal/#comment-1059 Grande!!! Trabalhei temporariamente sob a custódia do Cameron num projecto, admiro muito a liderança dele e o trabalho que ele faz. Sou um fã do Cameron. Marcos de Sousa Grande!!! Trabalhei temporariamente sob a custódia do Cameron num projecto, admiro muito a liderança dele e o trabalho que ele faz. Sou um fã do Cameron.

Marcos de Sousa

]]>