E se eu não usar padrões de design de software? [fechadas]


17

Que tipo de problemas posso enfrentar se não usar os Padrões de Design de Software? Você pode me falar sobre os problemas de abordar o design usando técnicas padrão de orientação a objetos?


24
Alguns padrões de design de software são bastante óbvios. Você precisaria conhecê-los todos muito bem para ter certeza de que não os está usando - provavelmente bem o suficiente para usá-los!
James McLeod

18
Como um ponto lateral do @JamesMcLeod, muitos "Padrões de Design" são muito óbvios e coisas que todo mundo faria de qualquer maneira. Por que lhes damos nomes, então? Para fins de comunicação. "Estou usando o padrão X" tem uma densidade semântica muito maior do que explicar sua solução na esperança de que o outro lado vá "Ah, sim! Eu também fiz isso, exceto que chamei minhas variáveis ​​...".
Phoshi #

6
@AJMansfield Alguns dos piores códigos que eu já vi envolvem excesso de entusiasmo por padrões de design.
Erik Reppen

5
@ErikReppen A culpa pelo uso excessivo de padrões de design deve ser atribuída à pessoa que faz isso. Na minha perspectiva, o problema principal não está nos padrões de design, mas na generalização excessiva (em parte devido à falta de supervisão da arquitetura) e na engenharia excessiva (às vezes por comitês de engenheiros).
Rwong #

5
"Design Patterns" é um léxico, não uma técnica.
quer

Respostas:


76

Você está perdendo o ponto.

Os padrões de design existem inerentemente ao fazer o design de software, assim como os padrões estruturais existentes no mundo. Mesmo se você não souber o nome das coisas, acabará descobrindo que certas estruturas físicas são adequadas para certos problemas. Você verá que uma forma triangular de madeira / barras de metal / etc é uma estrutura muito estável, mas apenas em um plano. Você encontrará tijolos quadrados com certas vantagens sobre os arredondados ...

Da mesma forma, certas estruturas de software são, de alguma forma, únicas ou ideais. Você acabará por encontrá-los e usá-los independentemente se souber os nomes para eles. Esse é o núcleo do que são os padrões de design - eles são nomes dessas estruturas que programadores experientes conhecem e usam de qualquer maneira. Dá aos programadores a capacidade de se comunicar de maneira muito mais uniforme e sucinta. Também permite que os programadores pensem no conceito de padrões de maneira mais consciente.

Então, os dois pontos principais que estou tentando fazer:

  1. Você não pode não utilizar padrões de projeto.
  2. Por não saber os nomes das coisas que você está usando, será difícil trabalhar em equipe.

12
+1: absolutamente certo. Comecei o desenvolvimento do OO antes que os padrões de design se tornassem conhecidos ou populares. Sim, também inventamos coisas como fábricas, singletons e algo que, quando você olhava de soslaio sob uma luz brilhante, parecia o padrão da estratégia. O ponto agora é que eu conheço os padrões de design, sei que as fábricas estavam bem, mas poderiam ter sido feitas melhor, os Singletons foram mal feitos e o que poderia ter sido um padrão de estratégia teria sido muito melhor se realmente tivesse sido um padrão de estratégia.
Preocupante binário

3
... Aprender sobre padrões de design e aprender a usá-los corretamente economiza muito tempo, é menos provável que você tente reinventar a roda, impede você de seguir o caminho do mau design e criar más soluções. Suga e aprende os padrões, usa-os quando eles trabalham para você e não os usa quando não o fizerem.
Worrier binário

1
E isso resume exatamente meus pontos de vista sobre padrões. São ferramentas maravilhosas para comunicar o que você está fazendo com outras pessoas. Você nunca as constrói exatamente porque cada problema é diferente. Mas eles são uma essência, uma direção e um conjunto aproximado de diretrizes a seguir, e facilita explicar aos outros o que diabos você está fazendo.
Matt D

+1 para a comparação com estruturas físicas. Eu acrescentaria que ajuda a construir uma casa se você já sabe que uma "treliça" é uma boa estrutura para suportar a carga de um telhado, em vez de experimentar e esperar que não desmorone.
kdgregory

39

Quem não se lembra do passado é condenado a repeti-lo.

Você não enfrentará nenhum problema específico além daqueles levantados pelo seu design. E, com o tempo, você acabará usando os padrões sem estar ciente, apenas gastando tempo para descobrir os padrões sozinho. O conhecimento prévio dos padrões facilita a identificação no design e traz a grande vantagem de que eles são comprovados por várias pessoas.

Tudo o que está sendo desenvolvido hoje se baseia amplamente em conhecimento anterior; não faria sentido ignorá-lo. Imagine construir um arranha-céu hoje sem conhecer os problemas enfrentados pelas pessoas que construíram catedrais algumas centenas de anos atrás.


10
"Cada citação tem uma citação igual e oposta." "Precisamos destruir o passado para merecer o futuro." (OK que um era Hitler para melhor para ignorá-lo ....)
Russell

20

Que tipo de problemas posso enfrentar se não usar os Padrões de Design de Software?

Você terá o problema de não conseguir escrever nenhum software.

Variáveis ​​são um padrão de design.

Métodos são um padrão de design.

Operadores - adição, subtração, etc. - são um padrão de design.

Instruções são um padrão de design.

Valores são um padrão de design.

As referências são um padrão de design.

Expressões são um padrão de design.

Classes são um padrão de design.

...

Tudo o que você faz em programação o tempo todo é um padrão de design . Na maioria das vezes, o padrão está tão arraigado em seu pensamento que você parou de pensar nele como "um padrão de design". As coisas que você precisa aprender como "o padrão singleton" e assim por diante são simplesmente padrões que ainda não foram inseridos no idioma que você está usando.

Você pode me falar sobre os problemas de abordar o design usando técnicas padrão de orientação a objetos?

Não. Não tenho ideia do que essa pergunta significa. Padrões de design são "técnicas padrão orientadas a objetos" - é isso que os torna padrões de design . Um padrão de design é uma técnica padrão para resolver um problema específico, particularmente (embora não necessariamente ) em uma linguagem orientada a objetos.


1
The things that you have to learn like "the singleton pattern" and so on are simply patterns that haven't (yet) been baked into whatever language you're using.- Essa é (quase) a definição de um padrão de design - uma construção de código flexível / facilmente reutilizável usada para superar uma limitação na própria linguagem, que é fácil de se comunicar com outras pessoas. Uma vez que faz parte do idioma, não é mais um padrão de design.
Izkata

1
@ Izkata: Então sua posição é que, digamos, o padrão de observador é impossível em C # porque o C # tem o padrão de observador incorporado na linguagem na forma de eventos? Isso é bobagem. O bit específico do idioma que é relevante para um padrão é a maneira canônica de implementar o padrão no idioma. Obviamente, os padrões de design podem ser usados ​​em idiomas que os suportam diretamente; esse é o objetivo de apoiá-los diretamente!
Eric Lippert

Eu nunca disse impossível, estava tentando implicar desnecessário . Java, por exemplo , não possui eventos, portanto, usa o padrão de design para simulá-los.
Izkata

@ Izkata: Estou confuso então. Você disse que uma vez que um padrão faz parte da linguagem, ele não é mais um padrão. Então, o "padrão do observador" é um padrão em Java, mas não em C #?
precisa

1
Ou, dito de outra maneira, um padrão de design é qualquer coisa que um programador faça, que pode ser descrito em inglês. Não tenho certeza se concordo totalmente com a definição, mas acho que ela reflete com precisão o que você está dizendo e, pelo menos, não tem o benefício de nenhum julgamento subjetivo que conta como padrão. É uma propriedade da análise do que programadores fazer, e é claro que não é possível para um programador para agir de uma forma que não pode ser analisado :-)
Steve Jessop

4

Compreender o ponto de um padrão de design é mais importante do que usá-lo à risca. Alguns padrões são, na OMI, tolos, pelo menos nos paradigmas linguísticos aos quais estou acostumado. A IMO, um programador que simplesmente usa padrões de design às cegas e sem realmente entendê-los, é um programador pior do que aquele que gostaria de pensar sobre as coisas. Mas alguém que se familiarize com as idéias e depois decida por si mesmo se vale a pena provavelmente será um programador muito mais forte do que qualquer um.

Dito isto, não tenho a menor idéia de qual é o objetivo do peso mosca e não tenho vergonha de admitir isso. (veja os comentários de outra entrada da Wikipedia que ajudou muito)

Eu recomendo a entrada da wikipedia sobre padrões de design. É muito concisa e claramente escrita. Muito útil para se ter uma idéia de por que alguém pode se preocupar com um determinado padrão de design ou não. Pessoalmente, acho os mais simples os mais úteis e não penso duas vezes em modificar uma determinada implementação de qualquer padrão para atender às minhas necessidades.

São idéias, não projetos. Em alguns idiomas, não são idéias muito boas. Em outros, eles são vistos como justificativos por superar as fraquezas de design de uma linguagem que podem ser melhor compensadas por menos complexidade. Independentemente disso, não faz mal examiná-los e tentar entender os desafios que eles devem superar antes de decidir sobre suas próprias soluções preferidas.

Que tipos de problemas você enfrentará? Você pode perder oportunidades e gastar mais tempo com problemas do que precisava, a menos que seja um gênio da programação e já tenha tudo resolvido. É importante manter um olhar crítico das idéias de programação populares, mas nunca é demais entender o que as pessoas pensam que estão resolvendo, porque isso dará mais clareza às suas próprias soluções / abordagens preferidas.


2
flyweight (não volante). Leia o primeiro parágrafo (e apenas o primeiro parágrafo) do artigo da Wikipedia e, em seguida, consulte Integer.valueOf (int) e considere quantas vezes isso evita a criação de novos números inteiros para valores comuns.

2
@MichaelT E caramba. Isso foi muito melhor do que qualquer coisa que eu já vi. Obrigado.
Erik Reppen

O problema que vejo na maioria das instruções de padrão de design é que elas tentam fornecer uma grande visão do projeto (o livro do GoF é sobre como escrever um processador de texto - não uma tarefa pequena). Mas às vezes são aplicáveis ​​a coisas muito menores (quase 'triviais'). 7 linhas de código podem descrever claramente o peso da mosca em algo que todo mundo usa constantemente. Muito mais fácil de entender do que os grandes projetos ou exemplos inventados.

1
@MichaelT Para mim, também é um bom exemplo de como obter um pouco de clareza em algo é útil para escrever código em geral, mesmo que essa ideia não tenha uso imediato no meu idioma principal, JavaScript, onde a herança e os fechamentos prototípicos são normalmente usados ​​para resolver isso. problema. Ter esse momento do a-ha ainda me deu algumas idéias relevantes.
Erik Reppen

2

O principal problema que você enfrentará é que você estará reinventando a roda . Eles são chamados de padrões porque aparecem frequentemente e de maneira previsível.


0

Mesmo se você seguir os padrões de design, poderá acabar com um design ruim. Os padrões de design são naturais e você acabará usando algum sabor dele em seu design. Você terá que se esforçar muito para não usar nenhum dos padrões. Não há razão para condenar os padrões de design, o mais importante é escolher os padrões certos para suas necessidades


-1

Você está usando padrões de design o tempo todo sem perceber. Muitas bibliotecas padrão em idiomas populares são projetadas com padrões de design em mente. Um exemplo é a FileReaderbiblioteca do Java, projetada usando o padrão de design do decorador . Agora, falando sobre seu próprio código, você não é obrigado a usar padrões de design (na maioria dos casos). Um padrão de design é uma "solução reutilizável para um problema que ocorre com frequência" , o que significa que o ajudará a escrever códigos mais limpos e mais sustentáveis, portanto depende de você o quanto você deseja evitar o código espaguete.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.