Quando é que um padrão de design piorar o seu software? [fechadas]

Question

Quando pode um padrão de design fazer o seu software pior?

Eu vi um programa onde eles usaram o padrão de fachada entre a GUI e da lógica. Eles consideraram que nenhum objeto pode ser transportado sobre isso, então foram usados ??apenas tipos primitivos que tornou difícil código.

Answer 1

Para programadores décadas têm muitas vezes passou um tempo fazendo software pior por aplicação de práticas que eles não entendem, ao invés de aprender por isso que a prática é bom. O uso de certas ferramentas / palavras-chave / frameworkes pode fazer um programador sentir sofisticado, quando eles estão apenas estragar as coisas. Alguns exemplos comuns:

• Jogando em lotes de try / catch / finally blocos podem fazer uma sensação programador como eles têm um erro de manipulação esquema, quando na verdade eles não fazem.
• Substituir SQL com procedimentos armazenados pode fazer programadores sentem que têm uma camada de acesso a dados que magicamente dá-lhes a eficiência, reuseability, encapsulamento, quando na verdade eles não fazem.
• Usando classes faz com que muitos programadores acreditam que estão participando de programação orientada a objeto, quando na verdade eles não são (ou estão apenas arranhando a superfície do OO).

Esta lista poderia continuar para sempre. Esta tendência tem sido sempre ao redor e sempre será, porque nós, humanos, sempre procurar atalhos. Vemos muito isso com padrões agora porque os padrões atualmente são populares. A raiz do problema é o mesmo:. Desenvolvedores não ter um respeito de como o desenvolvimento de software complicado é, e pensar um padrão cegamente implementado ou prática é um substituto para a aprendizagem e humildade

A solução? Difícil dizer. Você não pode ir para o errado embora entregando um desenvolvedor júnior Código completa ou algum tal, para ajudá-los a compreender que esta é tudo sobre a aplicação de princípios de situações particulares , e que grandes desenvolvedores de mantê-lo simples.

Answer 2

Quando você abusar dela, ou, às vezes pior, quando você usa um padrão unneccessarily. Este último me deixa doida porque quando eu analisar um pedaço de código, eu, naturalmente, primeiro supor que há uma razão para tudo lá dentro, e quando eu não consigo ver uma razão para alguma coisa, o mais seguro suposição padrão é que eu estou faltando alguma coisa. E desde que eu não quero correr o risco de quebrar o código em desconhecidos ou imprevisíveis maneiras, eu perca tempo tentando descobrir por que ele está lá antes de eu mexer com ele.

Answer 3

Quando se do nome é Singleton

Answer 4

A Design Pattern é simplesmente uma maneira de nomear e documentar uma estrutura de código comum. Como tal, você não deve concluir que todos os padrões são bons. As pessoas que fazem um bom trabalho de documentar padrões de projeto (por exemplo, o GoF) sempre incluir uma seção na descrição padrão descrevendo quando você deve, e não deve, usar o padrão. Como tal a metade do ponto da maioria dos livros padrão projeto é responder à pergunta: "Quando é que um padrão de design fazer o seu software pior?"

Muitos desenvolvedores inexperientes nunca se preocuparam em aprender a secção usos apropriados e acabam aplicando padrões onde eles são inadequados. Eu acho que esta é a causa de muita negatividade em torno padrões de projeto.

Em conclusão, a resposta a esta pergunta realmente deve ser: -. Ir e ler o padrão de projeto e ele vai dizer-lhe

Answer 5

Um padrão de design pode piorar o seu software se você abusar dela, aplicá-lo em uma situação errada . O bom senso deve ser o companheiro perfeito para um padrão de design.

O mau uso de padrões, por vezes, está associado a um falta de compreensão das forças associados com o problema ea solução padrão proposto para esse problema. Além disso, a intenção do padrão poderia ser mal interpretado levando a abusos.

Para uma melhor compreensão dos padrões que você também precisa de aprender sobre a Anti conceito padrão e ler muito mais do que o livro GOF. Uma sugestão é ler Padrão Hatching para complementar os conceitos de GOF.

Answer 6

É interessante que, durante o ano passado, eu já investiu uma quantidade razoável de tempo para aprender padrões de projeto e suas implementações - assim como não parece ser um golpe-back crescente contra Design Patterns. Design Patterns têm, de forma justa ou não, se juntou às fileiras de processos e metodologias que deveriam tornar o software uma habilidade quantificável - isto é, a falácia de que usá-los faria você escrever um código melhor. Eu acho que o problema com Design Patterns é que os programadores menos qualificados usá-los como uma "Martelo de Ouro". Eles aprendem o padrão de estratégia - que é uma coisa valiosa -. Mas então eles usá-lo em todos os lugares , o excesso de complicar o seu código e adicionando recursos desnecessários e "expansão"

Eu acredito que há imenso valor no refatoração para padrões, porque você está limpando o código existente. Os padrões são também ferramentas de comunicação importantes, que permitem descrever o seu código em termos de nível superior. Mas encher Design Patterns em seu software porque eles são legais e comercializáveis ??(a.k.a "Resume-Driven Development") é uma má idéia.

Answer 7

O que torna fácil difícil (EJB)

Answer 8

Quando é o padrão errado para o seu problema.

Answer 9

Em geral, quando um codificador toma a atitude que os padrões são o lego-like tijolos se constrói software fora de, você tem algum código realmente estranho.

Answer 10

O software vai piorar quando você usa padrões de projeto como blocos de construção absolutos, em vez de como azul-impressões para ajudar a resolver a codificação problemas.

Eles não foram feitos para ser os blocos em que o problema se enquadra. Eles não devem aparecer nas convenções de nomenclatura de objetos. Objetos não deve ser chamado * fábrica ou * Singleton, ou qualquer outro nome padrão. Eles não devem ser bloqueados para um padrão específico.

Eles são apenas muito bom "pontos de partida" para ajudar um construir códigos complexos mais rapidamente. Você pode (e deve) misturar e combinar as ideias conforme necessário. Documentação? Isso é o que os comentários são para, não o objeto namespace ...

Paul.

Answer 11

Ele é chamado de anti-padrão, e consulte os antipadrões:. Refatoração Software, Arquiteturas e Projetos em Crise livro para exemplos

Answer 12

Você pode ler sobre antipatterns aqui , por exemplo.

Answer 13

Eu acho que a estratégia padrão pode fazer software pior se não for necessário. O padrão de estratégia, basicamente, faz um pedaço de funcionalidade "pluggable", o que significa que pode mudar a diferentes implementações na mosca. Mas essa funcionalidade pluggable muitas vezes acrescenta muita complexidade (e sobrecarga às vezes adicional) com a configuração, e se não é necessário, é um desperdício. Eu vejo esse padrão abusado muitas vezes.

Answer 14

Levi, Eu só iria usar um padrão específico se tornou minha vida (e aqueles que são responsáveis ??pela manutenção do código) mais fácil. Acredito que adequada seleção padrão de design é tão importante como os comentários - talvez comentários são mais importantes? Você verá que os padrões de projeto, em sua maior parte, formalmente descrever as técnicas que nós, como desenvolvedores têm usado por anos.

TheEruditeTroglodyte

Answer 15

Qualquer padrão que é mal-entendido ou mal aplicados tenderia a tornar o código pior não melhor. Além disso, qualquer padrão que é aplicado apenas para a causa do padrão, por exemplo, "Estamos SOA agora!". Geralmente, se um padrão introduz um " code-cheiro ", em seguida, seu uso deve ser suspeito.

Answer 16

Eu diria que sempre que você escolher um padrão baseada na resolução de um problema, e não todos os problemas que seu software tem a intenção de resolver.

Por outro lado, tentando over-projetar uma solução para caber todos os possíveis casos de uso eventuais pode levá-lo a usar um padrão de design que é muito volumoso para caber a maioria dos seus casos de uso.

Assim, o padrão ideal / nível de adesão a esse padrão seria algo que cai entre os dois extremos.

Answer 17

Eu posso pensar de muitas maneiras um patter projeto pode dar errado. O livro GoF explica o problema, solução e desvantagens para todos os padrões que fala. - Um padrão é uma solução para um problema. Se esse problema não é o seu problema, então provavelmente ele vai se tornar um antipattern. - Um padrão tem desvantagens, e você deve estar ciente delas. - Quando você não precisa dele. Um padrão pode implicar um monte de aulas, e você está tentando resolver um problema que possa ter no futuro, mas não tem ainda. - Se você não entender como ele funciona e implementá-lo errado, ele se torna um antipattern também. Você vai acabar com um monte de aulas inúteis e código. - Quando você começar a ficar viciado nisso. Hierarquias que são demasiado profunda, mau uso de polimorfismo ou singletons, etc, podem representar um problema.

Há provavelmente outras razões também ...

Answer 18

Quando as pessoas analisar o código e passar mais tempo tentando entender o padrão do que a lógica de negócios. Padrões são boas, mas só se todos os envolvidos sabem como lê-los.