Como estudante de TI, recentemente recebi uma visão geral sobre os padrões de design de um de nossos professores. Eu entendi para que eles servem, mas alguns aspectos ainda continuam me incomodando.

Eles são realmente usados ​​pela maioria dos programadores?

Por falar em experiência, tive alguns problemas durante a programação, coisas que não consegui resolver por um tempo, mas o Google e algumas horas de pesquisa resolveram o meu problema. Se em algum lugar da web eu encontrar uma maneira de resolver meu problema, isso é um padrão de design? Estou usando?

E também, você (programadores) se vê à procura de padrões (para onde devo olhar, a propósito?) Quando inicia o desenvolvimento? Nesse caso, esse é certamente um hábito que devo começar a adotar.

ATUALIZAÇÃO: Acho que quando pergunto se os programadores os usam, pergunto se, quando você tem um problema para resolver, pensa "Oh, eu devo usar esse padrão".

Quando eu era um programador iniciante, adorava padrões de design. Não usei apenas padrões de design. Eu os infligi. Onde e quando eu pudesse. Eu era impiedoso. Aha! Padrão de observador! Pegue isso! Use um ouvinte! Proxy! AbstractFactory! Por que usar uma camada de abstração quando cinco funcionarão? Conversei com muitos programadores experientes e descobri que praticamente todo mundo que lê o GoF Book passa por esse estágio.

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 ajudam os padrões a emergir de uma maneira mais pragmática. Quando reconheço os padrões, posso continuar progredindo-os mais facilmente. Eu os reconheço, mas não tento mais forçá-los a codificar. Se um padrão de visitante surgir, é provavelmente porque refatorei a duplicação, não porque pensei antecipadamente nas semelhanças de renderizar uma árvore em vez de somar seus valores.

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

Se se reconhece ou não, a maioria dos programadores fazer padrões de uso.

No trabalho diário, no entanto, não se inicia a programação com um padrão em mente - se reconhece que um padrão surgiu no código e depois o nomeia.

Alguns dos padrões comuns são criados em alguns idiomas - por exemplo, o padrão do iterador é incorporado no C # com a foreachpalavra - chave.

Às vezes, você já conhece o padrão que estará usando como uma solução comum para o problema em questão (diga o padrão do repositório - você já sabe que deseja representar seus dados como uma coleção na memória).

Como está implícito na resposta pdr linked: padrões de design são nomes dados às coisas que as pessoas estavam fazendo de qualquer maneira , com o objetivo de facilitar o debate das pessoas.

Em geral, vale a pena aprendê-los quando começar, porque eles fornecem algumas dicas sobre as soluções que as pessoas encontraram para trabalhar, para que você possa aproveitar anos de experiência e tentativa e erro.

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

Se você usar um ou mais padrões existentes, então é ótimo, você tem nomes prontos que facilitarão o entendimento do código por outras pessoas.

De um modo geral, não. Há momentos em que os padrões emergem do meu código, mas, em geral, eu não os procuro e certamente não digo "Ah, o padrão de ponte resolveria 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. O código não é composto de permutação X de padrões. Sem mencionar que nem todos os padrões são realmente boas idéias, ou que algumas línguas têm soluções no nível da linguagem que são muito superiores a alguns padrões.

Sim, a maioria dos programadores que eu já encontrei usa 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 começarem a pensar "devemos usar padrões de design" em todo o lugar e refatorar sem piedade.

você os usa?

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

Se em algum lugar da web eu encontrar uma maneira de resolver meu problema, isso é um padrão de design?

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 um objetivo específico (ou evitar um problema específico). O que você pode encontrar pode não ser realmente um problema de design, mas uma sequência específica de etapas para programar uma determinada API. Por exemplo: existe uma certa sequência para estabelecer uma conexão de soquete. Faça errado e seu soquete não se comunicará. Essa sequência de etapas não constitui um padrão.

vocês (programadores) se encontram procurando padrões

Sim. Os padrões de design incorporam o axioma "prevenir é melhor do que remediar". Se você conseguir identificar um problema específico de design com antecedência, poderá impedir redesenhos em massa para acomodar alterações mais tarde. Portanto, vale a pena conhecer os padrões de design com antecedência e procurar lugares onde você precisa usá-los ao criar seu aplicativo.

onde devo olhar btw?

Como você é estudante, provavelmente não viu os problemas típicos que inspiram os padrões de design. Eu recomendo fortemente que você analise os padrões de design do Head First . Eles primeiro apresentam um problema de design e depois mostram como um padrão específico pode resolvê-lo / evitá-lo.

Os Padrões de Design não foram ensinados quando eu estava na escola. E, durante a maior parte da minha carreira em programação, trabalhei com código legado, não orientado a objetos. Nos últimos anos, tentei aprendê-los porque eles parecem uma boa idéia. No entanto, devo confessar que toda vez que peguei um livro ou tentei ler um tutorial sobre o assunto, meus olhos se arregalaram e eu realmente não aprendi nada de prático sobre eles.

Não acredito que acabei de admitir isso em público. Eu acho que provavelmente perdi qualquer crédito nerd que eu possa ter estabelecido ao longo dos anos.

Não procure por moda

Qualquer solução de programação padrão para um determinado problema pode ser considerada um padrão de design, não importa o quão popular eles sejam, ou se outros programadores os usarem 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 desejam ajustar seus problemas a eles quando é o contrário.

Lembre-se de que a convenção de design dos padrões de design tem um problema típico a ser resolvido; você pode até combinar padrões de design para resolver outros problemas maiores. Isso é típico das arquiteturas orientadas a serviços, basta ver alguns dos padrões SOA existentes .

Procure-os 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 decorador , o padrão de comando implementado e talvez até o flyweight .

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

Existem tantas soluções interessantes para escolher. Veja Patterns of Enterprise Architecture de Martin Fowler , também existem padrões de modelo de dados .

Apenas aprenda-os para quando chegar a hora

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

Torne-se um arquiteto

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

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

O padrão do iterador realmente tornou meu código mais confuso e adicionou complexidade desnecessária. Posso obter a mesma capacidade de manutenção usando typedefs para tipos de vetores STL. E quaisquer alterações que eu fizer na classe que está sendo iterada também precisam ser feitas na classe do iterador.

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

Eu usei o padrão de método de modelo por anos sem nem mesmo saber que era um "padrão de design".

O padrão Observador tem sido útil em alguns casos, às vezes não. Às vezes, é necessário prever a complexidade para determinar se vale a pena a complexidade de sobrecarga do padrão Observador. Temos um programa que usa cerca de 10 assinantes e pode haver muito mais, portanto o padrão observador / assinante tem sido útil. Outro programa, no entanto, possui dois monitores da GUI. Eu implementei o padrão de observador para este programa, e ele tem sido amplamente desnecessário, simplesmente porque aumentou a complexidade e não espero adicionar mais exibições.

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

Adicionando ao Lunivore. Eu gostaria de citar isso do primeiro livro

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

• Verifique se o software faz o que o cliente deseja
• Aplique bons princípios orientados a objetos
• Busque um design reutilizável e sustentável

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

Eles são realmente usados ​​pela maioria dos programadores?

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

Por falar em experiência, tive alguns problemas durante a programação, coisas que não consegui resolver por um tempo, mas o Google e algumas horas de pesquisa resolveram o meu problema. Se em algum lugar da web eu encontrar uma maneira de resolver meu problema, isso é um padrão de design? Estou usando?

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

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

E também, você (programadores) se vê à procura de padrões (onde eu devo olhar?) Quando você inicia o desenvolvimento? Nesse caso, esse é certamente um hábito que devo começar a adotar.

Às vezes, quando vejo o mesmo código repetidamente, posso encontrar uma maneira de refatorar o código em um padrão ou, se me lembro de uma solução para um problema semelhante envolvendo um padrão, eu o retiro e o uso. O Head First Design Patterns possui mais do que alguns padrões, enquanto a Refatoração seria uma sugestão para práticas de codificação que podem levar a encontrar vários padrões. Se você deseja outro possível ponto de partida, consulte os Padrões e práticas da Microsoft .

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

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

Você aprenderá padrões ao começar a trabalhar com projetos existentes. Existem tantos padrões por aí para você aprender, e não vale a pena dominar todos eles, pois depende do projeto em que você está trabalhando. Sempre que você encontrar um, aprenda sobre ele para ver como é usado.