Então é meio estranho fazer duas perguntas consecutivas, mas elas não são muito relacionadas e eu não queria combiná-las, mas não estou enviando spam, prometo!

De qualquer forma, eu sou recém-formado, e minha educação tocou apenas em padrões de design ... implementamos alguns simples, tocamos no fato de que havia outros mais complicados e fomos instruídos a recorrer ao livro do GoF se queria aprender mais. Minha pergunta é: vale a pena aprender os padrões no livro do GoF? Para mim, sempre pareceu contra-intuitivo tentar fazer com que um problema se encaixasse em um padrão clássico, mas obviamente o livro e os padrões são famosos por uma razão. Eles aparecem o suficiente para que eu os deva aprender?

Obrigado novamente!

Como sempre

Depende

Depende de quanto OOP você fez para reconhecer ou mesmo utilizar os padrões de design

Depende de quão disciplinado você é se aplicará os padrões uma vez aprendidos corretamente, e não enlouquecerá como o homem proverbial com um martelo

Por outro lado ... cinco dedos!

Se você fez alguns anos de trabalho sério em OOP ou tem um mentor confiável para mantê-lo nos trilhos ou você gosta de ler nerd em OOP, então, por todos os meios, compre o livro e estude-o.

Ajuda a conhecer os padrões para que você reconheça quando usá-los e quando não usá-los.

Sim, você deve aprendê-los.

Faz ainda mais sentido revisitá-los depois de adquirir alguma experiência , para poder compará-los com o que você conhece. Para alguns padrões, verificou-se que isso é algo que você descobriu, mas aprenderá algo mais geral sobre seu uso, vantagens e desvantagens, variantes e assim por diante. Outros podem parecer resolver diretamente os problemas com os quais você lidou e mostrar uma solução elegante que você não conhecia.

A grande maioria dos padrões é muito útil e comum . Outros podem não ser tão populares, mas ainda têm algum uso restrito onde são perfeitamente adequados.

Há mais uma razão pela qual vale a pena ler: ele ensinará como pensar . Claro, não é uma bala de prata, mas ainda uma inspiração inestimável.

Por último, mas não menos importante, nunca, nunca, em hipótese alguma, tente fazer com que um problema se encaixe em um padrão ou ferramenta . Isso é um pensamento muito ruim e perigoso! Entenda como a ferramenta funciona e use-a com sabedoria para lidar com o problema, nunca o contrário.

Quanto mais ferramentas você souber, melhor. Às vezes, uma ferramenta pode inspirar seu pensamento (em vez de resolver um problema diretamente); em outra, você combina alguns deles para obter uma ótima solução.

O livro do GOF é uma ótima fonte de muitas ferramentas úteis que usamos diariamente .

O benefício mais importante de conhecer um pouco sobre os Design Patters é que você sabe o que os termos significam. Em outras palavras, você conhece o vocabulário comum .

Esta é, para mim, a conquista mais importante de toda a turbulência dos Padrões de Design, que surgiu um vocabulário comum, no qual você pode usar apenas os nomes dos padrões específicos, e outros sabem imediatamente do que você está falando, sem precisar explicá-lo. . As coisas que os padrões descrevem são bem conhecidas pela maioria dos programadores, mas leva tempo para explicar o que você significa para os outros, tornando a comunicação mais fácil de conhecer os nomes dos padrões.

Exemplos são Visitor, Singleton e Decorators.

Em outras palavras, sugiro que você se familiarize pelo menos com os nomes e o que eles fazem.

SIM, mas com cautela!

A parte SIM:

Às vezes, encontramos problemas em nossos projetos. Às vezes, esses problemas são muito comuns; portanto, os padrões de design oferecem soluções bem testadas para esses problemas. Os principais benefícios de aprender padrões de design é que você pode criar uma solução de design muito mais rapidamente e se seus colegas de trabalho estão cientes do jargão do padrão de design , você pode explicar uma solução muito mais rapidamente.

O com parte cautelosa:

Os padrões de design não devem ser o santo graal das suas soluções. A solução mais simples (KISS) é mais desejada e muitas vezes os padrões de design tornam as coisas mais complexas. Se você estiver aprendendo padrões de design, também aprenda sobre antipadrões. Conheço algumas pessoas velhas que são contra os padrões de design e, de certa forma, concordo com elas porque, quando você não tem muita experiência em codificação, mas carrega a teoria dos padrões de design, pode acabar tornando as coisas muito mais difíceis para você e seus equipe.

Por fim, não pense que você precisa ajustar / alterar sua solução apenas para obedecer a um padrão de design. Pelo contrário, você pode dobrar um padrão de design para que ele caiba na sua solução. Tudo bem se você não estiver usando todos os ingredientes de uma receita de padrão de design, desde que você tenha uma solução melhor para o seu problema específico. Pense nos padrões de design como uma sugestão e não como a regra para sua solução.

Eu achei o método da Net Objectives de pensar nos padrões como mais benéfico. As pessoas que lêem o livro do GoF com muita frequência começam a supor que as estruturas que mostram, na notação de design e no código, são os padrões e que é sempre assim que parecem. Existe uma maneira diferente e discutivelmente melhor de ver isso.

Padrões são conjuntos de problemas semelhantes que podem ser resolvidos com certas fórmulas abstratas, não conjuntos de fórmulas que podem ser usadas para resolver vários problemas. O que isso significa é que o padrão já está lá antes mesmo de você começar a tentar fazer um design, o objetivo do designer é encontrá-lo , não impor.

Além disso, muitas pessoas olham para os padrões e dizem: "Ah, acabei de resolver isso por ... não usei nenhum padrão bobo". O fato é que "...." quase inevitavelmente descreve uma implementação de uma determinada solução de padrão. Por exemplo, uma série de indicadores de função poderia servir como uma Cadeia de Responsabilidade, mesmo que essa não seja a aparência da receita tradicional.

Com isso em mente, o foco no seu estudo de padrões deve estar nos problemas, não nos padrões. Aprenda os fatores motivadores dos padrões e como eles lidam com esses fatores. Isso permitirá que você veja os padrões do problema e, em seguida, aponte-os. Isso, juntamente com a linguagem que os padrões nos dão para falar sobre design, permite que você exponha um design adequado para responder às várias dificuldades que você está enfrentando atualmente.

SIM, em resumo, os padrões de aprendizado não valem apenas a pena ... você se limita por NÃO os aprender. Não quero descrever todos os princípios motivadores e o formato geral da solução quando digo: "Parece um visitante para mim".

Aqui está o site deles: http://www.netobjectives.com/PatternRepository/index.php?title=Main_Page

Os padrões de design descritos pelo GoF são uma extensão natural do paradigma OO. Se você não entender completamente os objetivos do OOP (encapsulamento, separação de preocupações, princípio DRY, modularidade etc.), tentar aplicar padrões de design com êxito não faz muito sentido.

Se, no entanto, você molhar os pés no POO do mundo real e tentar ser fiel aos valores do POO, inevitavelmente entrará em situações como as descritas pelo GoF, e é provável que invente soluções semelhantes às deles. Tendo resolvido muitos problemas semelhantes, você pode começar a ver padrões emergirem; neste ponto, faz sentido ler o livro; idealmente, você terá um senso de reconhecimento e apreciará imediatamente a elegância e a limpeza dos padrões propostos. As chances são de que você também considere alguns desses padrões sem cérebro (que, uma vez que você os conhece, muitos deles são). Você também poderá julgar bem se um determinado padrão é aplicável ou não em uma determinada situação.

E aqui está outro aviso: Só porque você conhece todos esses padrões não significa que você deve aplicá-los em qualquer lugar. Alguns deles são bastante inteligentes e as pessoas são tentadas a usá-los mesmo quando são terrivelmente inadequados, o padrão Singleton é o exemplo mais famoso (grande parte da controvérsia de Singleton vem do uso inadequado, por exemplo, quando não há benefício em ter um. restrição somente de instância).

Os padrões de design tentam resolver problemas de desing.

• Eles foram feitos AFAIK principalmente para idiomas OOP.
• Alguns dos problemas não existem na programação funcional (o Padrão de Comando é como criar funções de primeira classe, o Padrão de Estratégia se aproxima da função de ordem superior ...). Esses padrões são para idiomas (principalmente OOP) que não têm funcionalidade necessária.
• Eles são classificados em ordem alfabética. Vários padrões são composição de outros ou as idéias são compostas por aquelas que existiam antes.

Aprendi padrões mais tarde, depois de conhecer programação funcional, UML, criação de banco de dados, estruturas de dados e algoritmos. Na verdade, eu apenas estive na lista de design desses padrões na folha de dicas e assenti que já conhecia a maioria deles. Alguns eram realmente legais, como padrões singleton ou "comunicação" (visitante, mediador) ...

Concordo com os pontos apresentados em várias outras respostas sobre como pode ser perigoso aplicar padrões de design com pouca experiência.

Ainda assim, recomendo a leitura de pelo menos o primeiro capítulo do livro do GoF. A primeira seção apresentará os padrões de design, mas é realmente mais sobre os princípios do design de OO, e isso deve ser benéfico para ler e entender, mesmo com relativamente pouca experiência. (Algumas idéias-chave que eu lembro incluem "encapsular os conceitos que variam", "hierarquias de herança devem ser amplas, mas não profundas".) É quase uma pena que o trabalho seja conhecido principalmente por seus 23 padrões - sua discussão dos princípios de design do OO que informou esses padrões também é extremamente valioso.

Minha pergunta é: vale a pena aprender os padrões no livro do GoF?

Absolutamente! Você deve aprender não apenas padrões de design de software, mas técnicas de design em geral. Aprender soluções comuns para problemas comuns é um começo fantástico. Especialmente quando você começa a investigar os padrões e suas trocas.

Eles aparecem o suficiente para que eu os deva aprender?

O livro original do Gang of Four foi desenvolvido examinando muitos projetos de software e vendo técnicas que vários desenvolvedores usaram para resolver problemas. Os autores notaram algumas técnicas realmente boas, além de várias que foram aplicadas em projetos muito distintos e trabalharam para abstraí-las ainda mais para serem úteis independentemente do domínio.

sempre parecia contra-intuitivo tentar resolver um problema de acordo com um padrão clássico

Esse é o principal problema. Você não cria um problema adequado à solução. Em vez disso, o livro de padrões de design do Gang of Four possui uma seção "problema" para cada padrão, e outros catálogos de padrões têm seções semelhantes, que descrevem quando você deve aplicar cada padrão. Também descreve as "consequências" do uso do padrão - se você está tentando evitar uma conseqüência, usar o padrão não é a melhor ideia.