Quando devo usar - e não usar - padrões de design? [duplicado]

51

Em uma pergunta anterior sobre o estouro de pilha , FredOverflow mencionado nos comentários:

Note that patterns do not magically improve the quality of your code.

e

Any measure of quality you can imagine. Patterns are not a panacea. I once wrote a Tetris game with about 100 classes that incorporated all the patterns I knew at the time. Why use a simple if/else if you can use a pattern? OO is good, and patterns are even better, right? No, it was a terrible, over-engineered piece of crap.

Estou muito confuso com esses comentários: Eu sei que padrões de design ajudam a tornar o código reutilizável e legível, mas quando devo usar padrões de design de uso e talvez mais importante, quando devo evitar ser levado com eles?

    
por 7 revs, 3 users 50%user8 23.05.2017 / 14:40
fonte

15 respostas

91

KISS primeiro, os padrões mais tarde, talvez muito depois. Um padrão é um estado de espírito, principalmente. Nunca tente forçar seu código em um padrão específico, em vez disso, observe quais padrões começam a cristalizar fora de seu código e ajude-os um pouco.

Decidir "ok, vou escrever um programa que faça X usando o padrão Y" é uma receita para o desastre. Pode funcionar para programas hello world aptos para demonstrar as construções de código para padrões, mas não muito mais.

    
por 18.02.2011 / 12:26
fonte
47

Eu acho que a principal preocupação é que as pessoas muitas vezes têm uma tendência a abusar de padrões de design. Eles aprendem alguns, vêem a utilidade deles e, sem perceber, transformam esses poucos padrões em uma espécie de martelo dourado, que eles aplicam a tudo.

A chave não é necessariamente aprender os padrões em si. A chave é aprender a identificar os cenários e problemas que os padrões devem abordar. Em seguida, aplicar o padrão é simplesmente uma questão de usar a ferramenta certa para o trabalho. É o trabalho que deve ser identificado e entendido antes que a ferramenta possa ser escolhida.

E às vezes é uma configuração estranha e não há padrão de corte e secagem para resolvê-lo imediatamente. Nesse ponto, mais atenção deve ser dada ao problema do que à solução. Divida-o em problemas de componentes, identifique áreas do problema que compartilham traços comuns com problemas endereçados por padrões conhecidos, ajuste os padrões para se adequar ao problema, etc.

    
por 18.02.2011 / 12:25
fonte
21

Um padrão de design funciona melhor quando é usado como uma linguagem comum em sua equipe.

Com isso, você pode dizer algo como "essa classe é um Singleton que implementa nosso IHairyWidget Abstract Factory " e todos em sua equipe entendem o que isso significa sem ter que entrar em explicações detalhadas.

Quando os Padrões de Design falham é quando a equipe não os entende, ou quando eles são usados em demasia, eles param de tornar o design mais claro e, ao invés disso, tornam mais difícil entender o que realmente está acontecendo.

    
por 18.02.2011 / 12:32
fonte
13

talvez um pouco fora do assunto, mas acho que também cobre sua pergunta: sugiro-lhe um bom livro Refatorando-se para padrões :

This book introduces the theory and practice of pattern-directed refactorings: sequences of low-level refactorings that allow designers to safely move designs to, towards, or away from pattern implementations. Using code from real-world projects, Kerievsky documents the thinking and steps underlying over two dozen pattern-based design transformations. Along the way he offers insights into pattern differences and how to implement patterns in the simplest possible ways.

você encontrará exemplos quando os padrões de design forem bons de usar, bem como quando precisar sair deles, para não complicar a aplicação. E sim, a ideia principal é manter tudo o mais simples possível.

Boa resposta / conselho à sua pergunta foi no artigo Você reconhece os 4 primeiros sinais de alerta do padrão de design? , mas não consigo carregá-lo agora, erro 500. Não é grande, então usei o cache do google para obtê-lo :

Software design patterns can and do lead to over-engineering

Over-engineering is the process of over complicating something. In the case of programming, making your code more complex and possibly more flexible than it needs to be. More specifically, implementing complex software design patterns on simple problems.

1. Start simple not complex

How does this happen? Usually you program in extra functionality that you anticipate will be used or prove to be useful later. But what happens if this need never materialises? In most cases, the cruft gets left there. It doesn’t get removed. So the software system continues to grow in size and complexity with all these features that aren’t ever being used.

2. Be wary of the signs

This is perhaps different for everyone but I suspect in most cases, it isn’t really a conscious effort. But rather, it is something brought about by the fear of being stuck with an awkward, inelegant, inappropriate or simply put, bad design; being stuck with something that just isn’t flexible enough. Ironically, if you get to the point of over engineering or over applying patterns you are right back where you started.

Software design patterns appeal to programmers or developers because they allow them to naturally express and create beautiful architectures. It's a part of enjoying creative programming.

3. Consider refactoring to a pattern rather than starting from one

What might be a good way to avoid this design pattern abuse? Consider refactoring to a pattern rather than starting from one. Don’t start out trying to force a pattern into your design. Chances are your design could be much simpler without it. If you do find at a later stage that your design truly could benefit from a structured pattern, then refactor to allow for it. When you design, solve the problem in the simplest way possible. Simple light weight software is always a good thing. There are better ways of avoiding the under-engineered alternative where you get stuck with a design or solution that just isn’t flexible enough or doesn’t suit the problem.

4. Don’t force yourself to get it right the first time

Forcing software design patterns or structures into design just isn't the answer, that's just bad design. But prototyping or building an initial build0 (proof of concept build before production on the actual product begins) can help avoid this and the problem of over-engineering. Because you don't feel like you have to get it perfectly right the first time.

    
por 18.02.2011 / 12:27
fonte
8

when to stop doing everything using patterns ?

A questão é quando você começou a fazer tudo usando padrões? Nem todas as soluções se encaixam perfeitamente em um padrão de design existente e adotar um padrão pode significar que você limpe a limpeza de sua solução. Você pode descobrir que, em vez do padrão de design que resolve seu problema, você gera um problema adicional tentando forçar sua solução a se encaixar em um padrão de design.

Obviamente, se você escolher o padrão de design correto para um cenário específico, não terá um problema, mas escolher o correto é mais fácil falar do que fazer.

Eu vi o uso excessivo de padrões em projetos em que eles não são realmente necessários.

Acho que a chave é - Tente manter seu código limpo, modular e legível e certifique-se de que suas aulas não sejam strongmente acoplado . Eventualmente, você pode ver que você usou inadvertidamente uma variação em um padrão de design padrão. Talvez você tenha percebido isso no início do seu projeto antes de começar a codificar. Se você codifica como a maioria das pessoas que eu conheço (incluindo eu mesmo), então provavelmente não:)

    
por 18.02.2011 / 12:29
fonte
4

Bem, o mais importante é saber o problema que você está resolvendo. Então você precisa decidir se introduzir algum padrão lhe traria algumas vantagens sobre não usá-lo (ganho em desempenho, simplicidade ou qualquer outra coisa). Perguntas relacionadas: link

    
por 23.05.2017 / 14:40
fonte
3

A regra é que não há regra. Sua experiência (sucesso mais do que fracassos) lhe dirá quando usá-los puramente, quando adaptá-los ou quando não usá-los.

Há uma apresentação de Dan North, na qual ele fala um pouco sobre aprendizado e padrões

    
por 18.02.2011 / 12:26
fonte
3

O não. de padrões de design mencionados no original / de facto texto sobre o assunto, ou seja, GoF requer um pouco de experiência e, muitas vezes, várias releituras, e brain-storming com colegas competentes para dominar. Posto esse estágio, dado um problema, dada uma arquitetura, muitas vezes os padrões de design mais naturais surgem de maneira bastante óbvia. No entanto, qualquer tentativa de ajustar os padrões de projeto aos problemas, ou mapear os problemas para os padrões de projeto, é perigosa, caso em que é melhor consultar especialistas, atacar um pouco e tomá-los como uma experiência de aprendizado. A menos que você esteja bastante confortável com padrões de design de 10 nodos comumente usados, isso vai ficar um pouco complicado, e AFAIK, não há atalhos.

Eu já vi milhões de projetos de código SLOC C ++ com amplos exemplos de padrões de design de ajuste de força, então erros s.a. o uso excessivo não é muito incomum.

    
por 18.02.2011 / 12:29
fonte
3

É mais ou menos assim com qualquer tópico que exige que você aprenda e aplique regras :

  1. Se você é um novato, precisa seguir as regras porque não sabe melhor.
  2. Se você é um amador, você segue os papéis porque sabe por que precisa deles.
  3. Se você é um profissional, trabalha com as regras e não com elas, sabendo bem o que usar onde e quando elas não se aplicam.
  4. Se você é um especialista, você ignora as regras.
  5. Se você domina sua arte, você prefere as regras, pois seu código também deve ser visto na categoria de 1 a 3 pessoas. :)

É o mesmo com artes marciais, pintura, escrita, futebol, mecânica, corrida, etc ...

Como um cara # 5, você geralmente acaba ensinando aos caras # 1 - 4 como se tornar o topo, então isso sempre se aplica, mesmo em contextos competitivos.

( Como transcender e ignorar as regras explica isso em um sentido geral, mas provavelmente existem ensaios melhores por aí.

    
por 18.02.2011 / 16:03
fonte
2

Mantenha tudo o mais simples possível. Eu tenho que resolver um problema no entanto, você pode querer usar um padrão de design no entanto, em vez de reinventar a roda, como muitos padrões de design fornecem soluções para problemas comuns. Mas como eu disse: use-os apenas quando for realmente necessário.

    
por 18.02.2011 / 12:22
fonte
2

Talvez use o padrão KISS DRY SoC (sim, talvez não seja um padrão, mas parece divertido).

Mantenha-se simples, estúpido.
Não se repita.
Separação de preocupações.

Acho que esses três pontos devem ser inspiradores para qualquer programador.

    
por 18.02.2011 / 13:19
fonte
1

O problema com os "padrões" é que qualquer coisa pode ser considerada um padrão e geralmente é.

Eu desenvolvi código profissionalmente por um longo tempo antes de ouvir alguém falar sobre 'padrões', e consegui me virar bem por todos esses anos. Na verdade, quando olho para trás, muitas das coisas que escrevi na verdade seguiram alguns dos padrões bem conhecidos, pelo menos até certo ponto.

Meu ponto é que seguir qualquer padrão determinado rigidamente não é realmente a resposta. Aprenda sobre novos padrões, mas não fique preso a eles: eles vão mudar. Uma boa prática de codificação hoje não é o mesmo que uma boa prática de codificação dez anos atrás, e não importa o quão inteligentes sejam os programadores de hoje, você pode ter certeza de que, daqui a dez anos, as coisas consideradas boas práticas hoje terão sido superadas. p>

Off topic: Em uma nota pessoal, eu realmente odeio o uso da palavra 'patterns' neste contexto. Cheira a jargão desnecessário.

    
por 18.02.2011 / 14:19
fonte
0
Eu só vou saber disso. Quer dizer, eu até usei um padrão de design antes de conhecer a definição do padrão de design. É apenas uma boa codificação. Às vezes você poderá reconhecê-lo enquanto escreve os requisitos do projeto e, às vezes, precisa refatorar seu código.

jwenting disse KISS primeiro, os padrões mais tarde . Acho que os padrões são uma maneira de KISS executar um projeto porque você pode aplicar algo que sabe que funciona e poupará seu tempo no futuro.

A única coisa que pode dar errado é que existem muitas maneiras de implementar um único padrão de design, mesmo na mesma linguagem, então você precisa entender completamente qual é o seu problema .

    
por 18.02.2011 / 15:55
fonte
0

A maneira como você estrutura a lógica do seu código deve permitir que um recém-chegado a esse código possa interpretá-lo e modificá-lo. Ter um padrão apenas porque é uma prática recomendada não o levará a lugar algum se você não entender completamente o contexto de como, quem e onde esse código está e poderia ser usado.

O padrão "Keep it simple" é mais um senso comum do que um padrão e tem que ser parte do processo de pensamento de um desenvolvedor ao criar código. Assumir que todos obtenham um padrão específico também não é necessariamente correto. O ideal é que você queira um padrão que possa ser lido e identificado sem muito conhecimento dele.

    
por 18.02.2011 / 14:13
fonte
0

Geralmente, os padrões de design são usados para explicar ao público maior o que seu código realmente faz. Dessa forma, fica mais fácil para as pessoas entenderem o que você está fazendo. Raramente o usa como referência para encontrar soluções, já que um padrão pode ser implementado de muitas maneiras.

    
por 19.02.2011 / 04:59
fonte