Os padrões de design geralmente são uma força para o bem ou para o mal? [fechadas]

Ouvi dizer que os padrões de design são a melhor coisa desde o pão fatiado. Também ouvi dizer que os padrões de design tendem a exacerbar a "Síndrome do Segundo Sistema", que eles são muito usados ​​em excesso e que fazem seus usuários pensarem que são melhores designers do que realmente são.

Costumo me aproximar do campo anterior, mas recentemente tenho visto projetos em que quase todas as interações são substituídas por um relacionamento de observador, e tudo é um singleton.

Portanto, considerando os benefícios e os problemas, os padrões de design geralmente são bons ou ruins e por quê?

Os padrões de design são uma linguagem , não um conselho para escrever um programa ou um contrato. Seu uso principal é uma explicação a posteriori de como um componente ou sistema foi (ou será) implementado. Em vez de entrar em muitos detalhes, você pode apenas dizer algumas palavras que podem descrever a implementação suficientemente bem para que o ouvinte entenda como ela funciona e o que é importante nela.

Alex: Ei, como são criados os arquivos de configuração?

Bob: Eles são gerados por uma fábrica, na qual reside config.h.

Agora Alex sabe que a criação de arquivos de configuração envolve preparações não triviais, porque, caso contrário, sua criação não seria incluída em uma fábrica.

No entanto, se Bob era um impostor, e apenas usava padrões aqui e ali, Alex não sabia dizer nada sobre criação de configurações, porque Bob usava a fábrica em qualquer lugar. Isso também levaria a uma complexidade excessiva no programa.

Portanto, programe primeiro e depois localize os padrões no seu código, e não vice-versa. É assim que eles são efetivamente usados.

Os padrões de design são ótimos . Quando usados ​​adequadamente, tornam o código mais sustentável, mais fácil de ler e trabalhar. Parte de ser um bom programador é saber quando parar e ver que qualquer refatoração adicional superará os benefícios. O uso de padrões de design por si só não torna alguém um bom programador, mas saber quando e onde usá-lo faz. Assim como qualquer outra coisa neste mundo, os padrões de design podem ser levados ao extremo e ser abusados. Eu sei que ainda estou procurando (e vou procurar por muito tempo) o equilíbrio perfeito no meu código, onde todo padrão de design tem um propósito e se encaixa perfeitamente como uma peça de quebra-cabeça.

Os padrões de design são ótimos, se usados ​​corretamente.

É útil lembrar que a idéia de padrões de design se originou na arquitetura. A arquitetura pode variar bastante. No entanto, existem muitas idéias centrais presentes em qualquer edifício. Dessa maneira, pense nos padrões como blocos de construção do design. É importante observar que nem todo edifício inclui todos os padrões arquiteturais possíveis.

Digamos que você esteja projetando uma casa. Em vez de ter a porta da frente aberta para a rua, você deseja uma área protegida antes de entrar na casa, ou seja, uma ante-sala. Esta área ajustará um certo padrão. Nomeadamente, terá duas entradas, algumas paredes e provavelmente um telhado. Observe que o padrão não especifica portas, janelas ou quantas paredes. Na maioria das implementações, haverá duas portas, quatro paredes e talvez janelas. No entanto, o padrão descreve uma área fechada com duas entradas. Um leva para a ante-sala de fora da casa e o outro para o resto da casa. A chave aqui é que, se você quiser uma antecâmara, deve incluir uma área e fornecer duas entradas nessa área.

Os problemas típicos com os padrões de design na programação estão em excesso e a crença de que são balas de prata para corrigir qualquer problema. Eles não são. São maneiras de se comunicar e pensar em idéias úteis de programação. Se os bits de sintaxe de uma linguagem específica são os tijolos e a argamassa, os padrões descrevem maneiras úteis de organizá-las para atender a determinadas necessidades.

Considero os padrões de projeto mais um " conselho " do que um contrato imutável que absolutamente deve ser seguido. Por quê? Precisamente pela razão que você mencionou. Seguir um padrão de design em tudo leva a uma grande bagunça de código que anula o propósito de usar um padrão em primeiro lugar.

É por isso que odeio sites como o Java Practices . Claro que algumas das idéias são boas, mas o autor decidiu escrever um programa inteiro (mais uma estrutura) seguindo todos os padrões de design mencionados. O autor também escreveu todos os artigos com grandes citações assustadoras, fazendo o leitor pensar que as práticas reais de java são horríveis e devem ser evitadas como uma praga.

TL; DR: use padrões de design. Só não abuse deles

Seet também esta discussão no SO. De outro ponto de vista, os padrões de design do POV são códigos padronizados para compensar as deficiências da metodologia usada. Não sou fã de comemorar muito essas soluções alternativas.

Eu vou preferir aqueles no meio. Como o pôster apontou corretamente, uma compreensão de padrões não faz de você um bom desenvolvedor. Por outro lado, a compreensão do padrão o ajudará a se tornar um bom desenvolvedor.

Compreender o relacionamento dos padrões e ver um padrão em um projeto (enquanto estiver no estágio de concepção) é o que fará de você um bom desenvolvedor.

Costuma-se dizer que os padrões de design fornecem uma solução pronta para problemas de programação. Que tipo de problemas são eles? "Como posso alterar o comportamento do objeto, mas isolar as alterações do resto do sistema?"

Os padrões GoF são reconhecidos por fornecer esse isolamento (encapsulamento) do restante do sistema, mas geralmente é difícil saber qual parte do sistema recebe variabilidade através do uso de seus padrões de design. Em vez de seguir o esquema de classificação que eles propuseram (criacional, comportamental e estrutural), mapeei as diferenças dos padrões e criei outros dois esquemas para classificar seus padrões: ciclo de vida e hierarquia de encapsulamento de componentes.

Como você pode ver nesta tabela para a hierarquia de encapsulamento, os padrões de design podem ser aplicados em todos os níveis de um componente. Mas isso faria sentido? O componente precisará fornecer variação comportamental no nível de encapsulamento proposto e o padrão adequado é usado para esse nível? Se essas perguntas não forem respondidas adequadamente, os padrões de design provavelmente serão mal aplicados. Só porque um pivô vertical pode ser montado na cabine de um carro não a torna uma idéia inteligente.

Usando uma analogia ao dinheiro, um padrão de design deve ser pensado como uma solução com alto custo de capital, mas baixos custos operacionais. Os padrões de design custam uma fortuna adiantada em termos de codificação extra, detalhamento e o peso conceitual do indireção extra que eles criam. Eles também tendem a bloquear outros aspectos do seu design. Por exemplo, o uso do método de modelo obriga a programar em um estilo fortemente OO.

No entanto, se você precisar resolver muitos problemas intimamente relacionados, que variam de algumas maneiras pequenas, ou definitivamente precisará modificar muito um pedaço de código de maneiras específicas no futuro, os custos iniciais podem valer a pena porque o design padrões adicionam flexibilidade ao seu código. As modificações ou a solução para o segundo conjunto de problemas intimamente relacionados serão muito mais fáceis com os padrões do que sem.

Ambos os campos estão corretos - eles são uma força para o bem quando usados ​​corretamente, uma força para o mal se estiverem espalhados por todo o lugar.

Os padrões de design podem atrair você, mas o mesmo se aplica à codificação em geral. É fácil ser seduzido escrevendo a melhor caixa de ferramentas - você só precisa manter o YAGNI em mente para impedir que você se desvie do rumo e ter uma ideia de quanta estrutura o aplicativo precisa. Na OMI, isso se resume apenas ao indivíduo e é uma marca de sua experiência / julgamento.

Penso em datterns de design e não em algo que você está constantemente tentando aplicar ao seu código. Para mim, trata-se principalmente de uma linguagem comum para desenvolvedores. É mais fácil dizer "seguimos um padrão de construtor" do que explicar a coisa toda repetidamente.

Atualmente, estou relendo Patterns of Enterprise Application Architecture no momento, porque me deparei com muitos códigos que seguem um dos padrões desse livro. Eu não acho que foi escolhido intencionalmente para seguir um dos padrões, mas definitivamente ajuda se você puder dizer " é um script de transação " e todos entenderem claramente o que isso significa.

Mas gosto da ideia de que você pode escolher entre um catálogo preparado de padrões, quando cria uma nova funcionalidade ou um aplicativo totalmente novo. Por que reinventar tudo se existem soluções comprovadas para certos problemas?