Não é possível entender os padrões de design de programação

16

Eu tenho trabalhado com javascript nos últimos 4 anos. Estou muito confiante em minhas habilidades de resolução de problemas e posso ver que minha qualidade de código está melhorando. Tento me manter atualizado com a comunidade e atualmente estou trabalhando com o ES2015 e o React.js. No entanto, sinto que não consigo entender os padrões de design da programação. Eu sei onde encontrar recursos sobre isso e já li livros sobre isso. Confio em meus colegas de trabalho para tomar decisões sobre a estrutura do projeto, mas não tenho problemas em trabalhar nela.

Sempre que preciso iniciar algo sozinho, procuro esses dois caminhos: Se estou usando uma grande biblioteca / estrutura como o React.js, costumo copiar o que a comunidade está fazendo; Se estiver usando algo menor, usarei o padrão do módulo. Sei que, depois de entender melhor esse assunto, poderei tomar melhores decisões, mas por enquanto estou completamente perdido.

Devo procurar educação superior sobre isso? Preciso de um mentor sobre esse assunto? Eu sou apenas estúpido? Isso é realmente difícil de entender?

design-patterns javascript

— Abensur
fonte

6

Na minha opinião, algumas linguagens são mais 'perdoadoras' que outras quando se trata da necessidade de usar padrões de design. Linguagens compiladas fortemente tipadas (como Java e C #) são mais afetadas por design incorreto do que linguagens de script fracamente tipadas, como JavaScript e PHP. Para não dizer que os padrões de design não são úteis para ambos, é claro.

— Matthew

3

O tamanho do projeto também desempenha um papel significativo.

— Matthew

2

Nitpick @Matthew Eu não necessariamente chamar Java / C # fortemente digitado ...

— Jared Smith

2

@JaredSmith verdade, muitas vezes esqueço a distinção entre tipicamente fortemente digitado e estático.

— Matthew

6

Se você está tentando entender padrões de maneira geral , pare! Não há nada aqui! Um padrão é uma solução popular para um problema comum e alguém deu um nome a ele. É tudo o que há para isso. Talvez você ache difícil entender algum padrão específico - lembro-me de como usar efetivamente o padrão "visitante" para imitar o despacho duplo em Java - mas se você estiver procurando pelo molho secreto que vincula o "visitante" para dizer "objeto de transferência de dados", você não o encontrará. São apenas duas soluções populares para dois problemas comuns: alguém lhes deu nomes e os nomes ficaram.

— Solomon Slow

34

Os padrões de design de software são soluções conhecidas para problemas conhecidos. A maneira como você os entende é aprendendo os padrões, entendendo como eles funcionam e sabendo quando é apropriado aplicar cada um ao seu design de software.

A maneira como você aprende padrões de design de software é estudando-os, um de cada vez. É um processo de educação contínua. Se você deseja reduzir a pegada de aprendizado, estude os padrões relacionados diretamente às tecnologias que você está usando no momento.

Algumas coisas importantes a saber sobre padrões de design:

Alguns padrões de design são arquitetônicos por natureza. MVC e MVVM são exemplos de tais padrões. Você usa esses padrões quando precisa dos benefícios organizacionais e estruturais que eles fornecem.
Alguns padrões de design são soluções alternativas para deficiências nas linguagens de programação. Você não precisará desses padrões se usar uma linguagem de programação mais expressiva, mas geralmente não poderá fazer essa escolha. A maioria dos padrões GoF está nesta categoria .
Use um padrão de software apenas quando estiver tentando resolver o problema que o padrão foi projetado especificamente para resolver. Se você está escrevendo um aplicativo unindo padrões de software, está fazendo errado.
Não existe um padrão de software existente para todos os problemas de computação existentes. Nesse caso, a programação seria apenas um exercício de correspondência de padrões.
Alguns padrões são realmente antipadrões. A complexidade adicional introduzida por esses padrões supera os benefícios que eles fornecem. Você terá que decidir por si mesmo, padrão por padrão, qual desses padrões evitará.

— Robert Harvey
fonte

Boa resposta, embora eu discorde da afirmação de que a maioria dos padrões GoF são soluções alternativas para deficiências nas linguagens de programação. Frequentemente, alguns padrões são mais aplicáveis a determinados idiomas, sim, porque os idiomas tendem a ser projetados com certos problemas e soluções em mente.

— precisa saber é o seguinte

1

Os padrões Gof têm 20 anos. A maioria deles foi criada para corrigir problemas com o C ++, problemas que o Java herdou porque o Java é baseado no C ++.

— Robert Harvey

O paradoxo nesta resposta é a parte do "problema conhecido". É difícil entender esses "problemas conhecidos" se você nunca os experimentou.

— Fuhrmanator 20/08/16

2

Java não é baseado em C ++. A sintaxe javas é inspirada em C ++, mas certamente não é baseada nela. os dois idiomas funcionam de maneira bem diferente. Do fato de que Java hardware abstact, gerencia a memória por si só, por não ter Templates mas sim genéricos etc.

— Polygnome

4

A abordagem de todo mundo para o aprendizado é um pouco diferente, e eu não tenho idéia de qual é a sua abordagem geral, mas acredito que você está fazendo um desserviço ao se rotular de "estúpido".

Pessoalmente, pelas minhas observações sobre o que muitos chamariam de "bem-sucedidos" engenheiros de software, designers, etc., todos têm um tema em comum no aprendizado: "experiência". Acredito que essa seja sua "educação superior" e você aprenderá mais rapidamente com ela do que comprando toneladas de livros da Amazon e lendo-os (um mau hábito meu).

Portanto, por exemplo, pegue um padrão GOF como o padrão de comando e implemente-o na sua escolha de idioma. Entenda quais benefícios ela oferece e as desvantagens. Os vários livros sobre padrões de design explicam isso para você, mas acho que é melhor aplicar esse conhecimento praticamente e aprender com ele. Não descarte o material de leitura, eles têm um objetivo, mas o mundo da TI dificilmente é um exercício de manual. Dito isto, essa é minha opinião e visão do mundo da TI e, em parte, representa lutas próprias ao iniciar minha carreira em engenharia de software. Além disso, vejo uma questão importante, mesmo com desenvolvedores de software muito experientes, é a impaciência e o esquecimento de gostar do que estão fazendo. Portanto, dedique um tempo ao seu aprendizado e lembre-se de realmente apreciar o que está fazendo, caso contrário, por que se preocupar em investir tempo nisso?

Além disso, faça uso da experiência prática de outras pessoas. Há uma infinidade de soluções de código aberto, ruins e boas, e você pode aprender com elas. Veja como eles aplicaram padrões e pense em como você o enfrentaria de maneira diferente.

Portanto, meu conselho geral é que, se você achar que sua abordagem está errada, mude. Olhe para as pessoas ao seu redor que você sente que estão aprendendo o material que você sente que não está entendendo e observe o que elas estão fazendo ou até pergunte a elas.

— Desolate Planet
fonte

1

Eu realmente acho que a programação é como o jogo de xadrez. Você pode ter algum talento nativo, jogar todo o dia, mas se não ler alguns livros sobre xadrez, não poderá progredir e, mais importante, não poderá apreciar a beleza do jogo.

— Adrian Iftode

@AdrianIftode - concordou. Como mencionado, eu não descartaria livros, blogs ou qualquer material de leitura, mas é um problema comum que encontrei com pessoas que se esforçam para dominar uma linguagem / plataforma / estrutura de programação etc. e, aparentemente, elas fizeram pouca codificação e / ou prática mas tenha lido todos os livros em que você pode agitar.

— Desolate Planet

@AdrianIftode Bem, não exatamente. Jogando xadrez sem ler livros, você ainda pode aprender muito sobre o jogo. A única diferença é que você não está aprendendo o mais rápido possível, aproveitando algumas experiências e pensamentos do mestre de xadrez. Por outro lado, pensando em certas coisas, você pode se deparar com uma ou duas soluções que foram totalmente ignoradas pelas pessoas que aprendem apenas com os mestres de xadrez e que podem ser úteis para sua vantagem. No final, acredito que uma mistura dos dois tipos de aprendizado fornece o melhor benefício. No xadrez, bem como na programação.

— cmaster - reinstala monica em

1

A resposta curta é que você não precisa deles. Você pode escrever código sem eles. Como Matthew disse nos comentários, isso é particularmente verdadeiro no JavaScript, onde a linguagem é bastante flexível e os projetos tendem a ser menores. Mas se você está programando há 4 anos, acho difícil acreditar que você não tenha tropeçado em coisas que parecem repetitivas ou estranhas. É nessas áreas que você está redescobrindo ou faltando padrões de design.

Exemplo: o sistema de eventos do JavaScript geralmente é inadequado para a tarefa em questão. Você nunca se sente capaz de combinar ou transformar fluxos de eventos? Ou essa série de eventos eram valores de primeira classe por si mesmos? Você precisa dos padrões Mediador e / ou Observador. Precisa de ligação de dados bidirecional? Mesma história.

A hierarquia frágil do protótipo caiu? Padrões Mixin / Trait / Subclass Factory para o resgate.

— Jared Smith
fonte

4

É praticamente impossível escrever qualquer programa não trivial sem usar nenhum padrão de design; normalmente você também usará muitos programas comuns. O que você não precisa é ser capaz de reconhecer os padrões que você está usando pelo nome. Você pode escrever um código de trabalho, mesmo que não consiga nomear todos os padrões de design que estiver usando em todo o código.

— Servy

Os padrões de design do @Servy são abstrações, abstrações não são estritamente necessárias. Você sempre pode escrever uma implementação pontual ad hoc do comportamento subjacente ... de novo e de novo e de novo. Por exemplo, no exemplo que eu dei sobre os eventos, é possível conectar manualmente todas as partes interessadas e depois alterá-las sempre que os requisitos forem alterados, é apenas uma merda em comparação ao uso de pub / sub. Para as subclasses, é possível (se for um desperdício) codificar manualmente todas as possibilidades com várias classes pontuais, mas isso não é tão bom.

— Jared Smith

1

Os padrões de design podem ficar muito amplos. Muitas vezes, padrões de design mais amplos são tão óbvios que nem pensamos neles como padrões de design (especialmente quando eles têm suporte especial a idiomas). Um loop é um padrão de design. Funções são um padrão de design. Objetos são um padrão de design.

— Servy

@ Service, se é assim que você está usando o termo, então eu não discordo, mas tive a impressão de que o OP significava especificamente padrões do GOFish.

— Jared Smith

1

Os padrões de design do @JaredSmith não são abstrações. Mesmo se você implementá-los repetidamente para o problema concreto que você tem, eles ainda são padrões . Você não precisa escrever uma classe genérica do Observer e usá-la para usar o padrão Observer . Escrever observadores e métodos concretos para registrá-los e notificá-los ainda está usando o padrão. o difícil é reconhecer o padrão. Às vezes você está usando um padrão, mesmo sem saber seu nome,

— Polygnome

1

Encontre um mentor, alguém com uma experiência muito boa para aprender. Pergunte a ele, observe o código, envie uma revisão de código e tente colaborar com ele. Esta é a melhor maneira de aprimorar suas habilidades de codificação.

extra:

Colabore com um projeto OSS simples que você gosta
Quando houver duas maneiras de resolver o mesmo problema, sempre escolha a mais simples
Crie uma experiência extra com projetos paralelos em que você é livre para cometer todo tipo de erro estranho e aprenderá o padrão de design "da maneira mais difícil" (tm)

— Motocarota
fonte