Quando eu era um programador iniciante, adorava padrões de design. Eu não usei apenas padrões de design. Eu os infligi. Onde e quando eu pudesse. Eu fui impiedoso. Ah! Padrão de observador! Pegue isso! Use um ouvinte! Proxy! AbstractFactory! Por que usar uma camada de abstração quando cinco o fazem? Falei com muitos programadores experientes e descobri que quase todos que lêem o GoF Book passam por este estágio.

Os programadores iniciantes não usam padrões de design. Eles abusam de padrões de design.

Mais recentemente, acho que manter em mente princípios como o Princípio da Responsabilidade Única, e escrever testes primeiro, ajuda os padrões a emergirem de uma maneira mais pragmática. Quando reconheço os padrões, posso continuar a progredir com mais facilidade. Eu os reconheço, mas não tentei forçá-los no código. Se um padrão de visitante surgir é provavelmente porque eu refatorei a duplicação, não porque eu pensei antes sobre as semelhanças de renderizar uma árvore versus somar seus valores.

Programadores experientes não usam padrões de design. Padrões de design os usam.

Se alguém os reconhece ou não, a maioria dos programadores fazem padrões de uso.

Alguns dos padrões comuns são criados em algumas linguagens - por exemplo, o padrão de iterador embutido em C # com o foreach palavra-chave.

Às vezes, você já conhece o padrão que será usado como uma solução comum para o problema em questão (por exemplo, o padrão de repositório - você já sabe que quer representar seus dados como uma coleção na memória).

Como está implícito na resposta pdr ligada: os padrões de design são nomes dados às coisas que as pessoas estavam fazendo de qualquer maneira , com o objetivo de facilitar a discussão sobre essas coisas. / p>

Em geral, vale a pena aprendê-las ao iniciar, porque elas fornecem algumas dicas sobre as soluções que as pessoas encontraram para trabalhar, para que você possa aproveitar anos de experiência e avaliação & erro.

A discussão sobre a motivação de problemas incluídos nos padrões pode fornecer informações sobre as boas maneiras de atacar seu problema, mas, a menos que seu conhecimento padrão permita reconhecer que existe uma solução existente bem conhecida, você ainda precisa se concentrar em resolvendo o problema primeiro.

Se ele usar um ou mais padrões existentes, ótimo, você terá nomes prontos que facilitarão a compreensão do código por outras pessoas.

De um modo geral, não. Há momentos em que os padrões surgem do meu código, mas em geral eu não procuro por eles e certamente não digo "Oh, o padrão de ponte resolveria o meu problema!".

Aqui está a coisa. A maioria dos padrões é abusada e mal utilizada, sem que as pessoas considerem se são de bom design. Padrões não são átomos. Código não é composto de permutação de padrões X. Sem mencionar que nem todos os padrões são realmente boas ideias, ou que algumas linguagens têm soluções em nível de linguagem que são muito superiores a alguns padrões.

sim, a maioria dos programadores que já encontrei usam o padrão mais comum que existe, o Big Ball of Mud . Eles geralmente começam com arquiteturas bem projetadas, mas geralmente acabam aqui, especialmente se eles começarem a pensar que "devemos usar padrões de design" em todo o lugar e refatorar impiedosamente.

do you use them?

Sim, programadores experientes definitivamente fazem. Você pode evitar usar a maioria dos padrões de design (excluindo coisas singleton simples) por enquanto; mas quanto mais você programar e os sistemas mais complexos que você construir, mais você sentirá a necessidade de usar padrões de design. Se você ainda evitá-lo, começará a sentir a dor quando precisar expandir o sistema e alterá-lo de acordo com os novos requisitos.

If somewhere in the web I find a way to solve my problem, is this a design pattern?

Não necessariamente. Um padrão de design refere-se a uma maneira específica de projetar classes, seus comportamentos e interações para atingir uma meta específica (ou evitar um problema específico). O que você pode ter encontrado pode não ser realmente um problema de design, mas uma sequência específica de etapas para programar uma determinada API. Por exemplo: há uma certa seqüência para estabelecer uma conexão de soquete. Faça errado e seu soquete não vai se comunicar. Essa sequência de etapas não constitui um padrão.

do you (programmers) find yourself looking for patterns

Sim. Padrões de design incorporam o axioma "é melhor prevenir do que remediar". Se você puder detectar um determinado problema de projeto antecipado, poderá evitar reformulações em massa para acomodar alterações posteriormente. Por isso, vale a pena conhecer os padrões de projeto de antemão e procurar lugares onde você precise usá-los enquanto cria seu aplicativo.

where am I supposed to look btw?

Como você é um aluno, provavelmente não viu os problemas típicos que inspiram padrões de design. Eu recomendo strongmente que você olhe para Head First Design Patterns . Primeiro, eles apresentam um problema de projeto e mostram como um determinado padrão pode resolvê-lo / evitá-lo.

Design Patterns não foram ensinados quando eu estava na escola. E, durante a maior parte da minha carreira de programação, trabalhei com código legado e não orientado a objetos. Nos últimos anos, tentei aprendê-las porque elas soam como uma boa ideia. No entanto, devo confessar que toda vez que eu peguei um livro ou tentei ler um tutorial sobre o assunto, meus olhos brilharam e eu realmente não aprendi nada de prático sobre eles.

Eu não posso acreditar que acabei de admitir isso em público. Acho que provavelmente acabei de perder qualquer credibilidade que eu possa ter estabelecido ao longo dos anos.

Não procure por trendiness

Qualquer solução de programação padrão para um determinado problema pode ser considerada um padrão de projeto, não importa quão populares eles sejam, ou se outros programadores os usam ou não.

Você já pode estar usando um padrão de design que ainda não foi inventado / especificado.

Não tente usá-los, tente pensar nos termos deles

O problema com os padrões de design é que às vezes os programadores querem encaixar seus problemas neles quando é o contrário.

Lembre-se que a convenção de design de padrões de projeto tem um problema típico a ser resolvido, você pode até mesmo combinar padrões de projeto para lidar com outros problemas maiores. Isso é típico em Arquiteturas Orientadas a Serviços, apenas veja alguns dos padrões SOA .

Procure por eles na natureza

Existem muitos projetos de código aberto nos quais você encontrará padrões de design aplicados. Um exemplo que vem à mente é o Joomla: você encontrará singletons , observadores . As bibliotecas da GUI terão o padrão de decorador , padrão de comando implementado, e talvez até flyweight .

Existem outros padrões, como padrões de dados, por exemplo, somente o Projeto Doctrine usou, o padrão de registro ativo ( 1.x), padrão do gerenciador de entidades (2.x), unidade de trabalho , repositório , objeto de consulta , mapeamento de metadados , padrão de estratégia e padrão de decorador .

Existem tantas soluções interessantes para escolher. Veja Padrões de Arquitetura Empresarial de Martin Fowler , há também padrões de modelo de dados .

Apenas aprenda-os quando chegar a hora

Aprenda-os, conheça-os, fique obcecado com eles e, quando a hora chegar, você saberá como resolver o problema de programação x, você já será um programador melhor.

Torne-se um arquiteto

Eu diria que ser capaz de pensar em termos padrão para resolver problemas, efetivamente transforma você em um arquiteto de software . Mesmo que você não queira ser um arquiteto de software, suas soluções terão mais qualidade técnica, melhor escalabilidade - em termos de design - por padrão.

Eu programei por aproximadamente 7 anos em C ++ e aprendi padrões há 2 anos. A maioria dos padrões provavelmente tem alguns aplicativos, mas no meu uso, alguns são melhores que outros. Você tem que pensar porque você os está usando.

O padrão do iterador tornou meu código mais confuso e adicionou complexidade desnecessária. Eu posso obter a mesma facilidade de manutenção usando typedefs para tipos de vetores STL. E todas as alterações que eu faço para a classe que está sendo iterada eu também tenho que fazer para a classe iterator.

O método de fábrica, no entanto, tem sido extremamente útil, baseado no polimorfismo que ele fornece. Eu esqueci quem disse isso, mas a afirmação "reutilização significa que código antigo pode usar código novo", é definitivamente verdade com o padrão de fábrica.

Eu usei o padrão de modelo de modelo por anos sem saber que era um "padrão de design".

O padrão Observer foi útil em alguns casos, às vezes não. Às vezes, você precisa prever a complexidade para determinar se a complexidade de sobrecarga do padrão Observer vale a pena. Nós temos um programa que usa cerca de 10 assinantes e pode haver muitos mais, então o padrão de observador / assinante tem sido útil. Outro programa, no entanto, tem duas exibições de GUI. Eu implementei o padrão de observador para este programa, e ele tem sido em grande parte desnecessário, simplesmente porque adicionou complexidade e eu não antecipo adicionar mais displays.

Eu acho que aqueles que dizem usar padrões sempre assumem que seu programa será infinitamente complexo, mas, como com tudo, existe um ponto de equilíbrio em termos de complexidade.

Adicionando ao Lunivore. Eu gostaria de citar isso do primeiro livro da cabeça

        ## **Three steps to great software** ##     

• Verifique se o software faz o que o cliente quer
• Aplicar bons princípios orientados a objetos
• Procure um design reutilizável e sustentável

É durante o terceiro estágio, depois que o sistema está funcionando da maneira esperada. É hora de aplicar os padrões para preparar o software para os próximos anos.

Are they really used by the majority of programmers?

Eu acho que sim. No ADO.Net, existe uma classe DataAdapter para dar um exemplo simples, embora dependendo de qual área você deseja especializar os padrões podem variar.

Speaking of experience, I've had some troubles while programming, things I could not solve for a while, but google and some hours of research solved my problem. If somewhere in the web I find a way to solve my problem, is this a design pattern? Am I using it?

Não, isso não é um padrão de design em minha mente. Um padrão de design tende a ter algum arranjo de classes e métodos que definem a receita de um padrão.

Eu prefiro pensar no que você fez lá como uma prática comum. Cuidado com copiar e colar codificação embora.

And also, do you (programmers) find yourself looking for patterns (where am I supposed to look btw?) when you start the development? If so, this is certainly a habit that I must start to embrace.

Por vezes, à medida que vejo o mesmo código várias vezes, posso encontrar uma forma de refatorar o código num padrão ou, se me lembrar de uma solução para um problema semelhante que envolva um padrão, retirá-lo-ei e utilizá-lo-ei. Os Head First Design Patterns têm mais do que alguns padrões enquanto Refactoring seria uma sugestão para práticas de codificação que podem levar a pessoa a encontrar vários padrões. Se você quiser outro possível ponto de partida, veja os Padrões e práticas da Microsoft .

Padrões de aprendizagem não estão apenas aprendendo alguma coisa. Você aprende o que você pode fazer com linguagens de programação. Eu mesmo aprendi muito sobre programação orientada a objetos apenas aprendendo como um padrão funciona (o padrão padrão neste caso).

Como mencionado por Oded, a maioria dos programadores os usa algumas vezes sem reconhecê-lo. A beleza dos padrões é que você pode abordar problemas específicos com um padrão predefinido, para não precisar pensar muito sobre as coisas arquitetônicas.

Você aprenderá padrões quando começar a trabalhar com projetos existentes. Existem muitos padrões para você aprender, e não vale a pena dominar todos eles, pois depende do projeto em que você está trabalhando. Sempre que você topar com um, saiba mais sobre como ele é usado.