Como você deve explicar os Design Patterns para pessoas fora do Software World

Quero explicar os padrões de design para minha sobrinha, mas sempre luto para fazê-lo. Isso se deve em grande parte à minha falta de compreensão clara dos padrões de design. Como você sugere explicar padrões como MVC, Singleton, Factory, Repository etc. em termos tão simples que até crianças de 10 anos de idade podem entender.

Estou procurando exemplos que possam facilitar a compreensão de padrões. Exemplos com brinquedos, filmes, música etc.

Eu acho que o começo do artigo da Wikipedia é provavelmente um bom começo:

A design pattern is a general reusable solution to a commonly occurring problem.

Ou você está querendo explicar as especificidades desses padrões particulares?

Depende do motivo que você deseja explicar. Se você quiser apenas explicar a idéia de padrões, eu usaria exemplos da arquitetura em A Pattern Language. Esses pesquisadores descobriram que certos aspectos de um prédio ou sala fazem com que as pessoas gostem de morar ou trabalhar naquele prédio ou sala - em todo o mundo em diferentes culturas, com diferentes materiais de construção e em diferentes tipos de bairros. Como "Luz nos dois lados", por exemplo. Salas com janelas em duas paredes são muito mais agradáveis ​​do que aquelas com apenas uma (ou nenhuma). Existem padrões assim também no software - mesmo usando diferentes linguagens de programação, alguns padrões se repetem. E mesmo em softwares muito diferentes - um jogo, algo para cálculos financeiros, o mecanismo dentro do Facebook e assim por diante.

Então, se você quiser falar sobre um padrão específico (não sei por quê, para uma criança de dez anos), pode começar dando exemplos de onde é usado antes de tentar explicar como ele funciona. Assim, o Composite permite evitar recursões explícitas ao calcular o peso de uma mala, somando o peso do contêiner e o total de todos os contêineres e itens soltos que ele contém, mas também funciona para calcular a carga salarial em uma corporação ou capacidade em um complexo de fabricação. Se isso é um pouco interessante para a criança de dez anos, você pode tentar explicar como ela funciona.

Os padrões de design existem porque algumas pessoas perceberam que havia maneiras de fazer com que bits de software funcionassem bem juntos e queriam compartilhar suas idéias.

Você pode pensar em padrões de design da mesma maneira que pensa em grupos de pessoas. Por exemplo, às vezes temos uma pessoa que facilita todas as nossas reuniões. É como um padrão de controlador, que facilita as interações entre objetos.

Ou imagine uma platéia, onde alguém na frente da sala observe as pessoas levantando as mãos e repita a pergunta para que todos os outros possam ouvir, ou talvez reajam respondendo. Isso seria semelhante a um padrão Assunto / Observador.

Existem padrões que se comportam como tradutores (o padrão do Adaptador), como guardas de segurança (o Proxy), como especialistas em um campo (Singletons) ou como pessoas que verificam se o seu carro está funcionando (Validadores).

A diferença entre objetos e pessoas é que podemos criar quantos objetos quisermos e ter várias cópias diferentes deles. Isso torna importante entender quais responsabilidades os objetos devem ter, manter as responsabilidades pequenas e tentar não duplicar o que fazem, para que o software não fique muito complicado. Os especialistas têm muita experiência nisso e nos deram esses padrões de interatividade entre o software eficaz, para que possamos decidir que tipo de papel é a melhor metáfora para o trabalho que estamos tentando fazer e obter as software para colaborar da maneira mais apropriada.

Diga a ela que eles são usados ​​para criar componentes individuais de um sistema, como técnicas de culinária são usadas para criar uma refeição / prato. Imagine que você está preparando o jantar, com batatas, carne e vegetais. Você decide que as batatas cozidas e amassadas, a carne grelhada e os legumes cozidos no vapor. Você usa seu padrão de design de grelha para cozinhar os padrões de carne, fervura e purê para as batatas e o padrão de vapor para os vegetais.

A maioria desses padrões de design faz parte do design orientado a objetos. Você não pode realmente explicá-las a alguém sem entender o OOD. Você pode descrever o objetivo que alcança com determinado padrão, mas não como ele funciona nem por que precisa dele. A menos que você explique todo o OOD.

Os padrões de design foram descritos pela primeira vez para arquitetura. Coisas como localização da praça, prédios e outros layouts geralmente repetidos. Você pode começar por aí. Coisas como a entrada principal estão voltadas para a rua, porta para o canto da sala e qualquer outra coisa que você possa imaginar. Os padrões do autor original não foram amplamente utilizados. É relatado que agora ele afirma que os próprios padrões não são suficientes.

Discuta como mover as coisas pela sala. Coloque uma cadeira em frente à porta. Faria sentido mover as janelas ou portas para outro lugar. Por que ou por que não?

Tente algo como arrumar um lugar à mesa. Tente organizar as coisas por tamanho, afastando-se de você. Não é o padrão normal e difícil de trabalhar. Configure normalmente. É um layout adequado para um copo rápido de suco? Os padrões nem sempre são apropriados.

Vivemos com padrões o tempo todo. Pegue três ou quatro livros e comece a folhear eles. Há um padrão óbvio no layout; página de título, sumário, conteúdo e índice. Nem todos os componentes são necessários, mas seria confuso vê-los fora do lugar.

Os padrões de design são, para o desenvolvimento de software, o que são os gabaritos para trabalhar madeira. É uma ferramenta com a qual você pode fazer 'cortes' conhecidos para usar em projetos maiores.

Observe que você não precisa do gabarito para fazer o corte, é apenas mais fácil em algumas circunstâncias.

Sinto que minha outra resposta representa o caso geral, mas o OP comentou solicitando detalhes (então achei que merecia uma resposta separada). Infelizmente, não estou familiarizado com o padrão do Repositório, mas vou dar uma facada nos outros. Como regra, acho que a melhor maneira de explicar isso é através de qual problema você deseja resolver, por que deseja resolvê-lo e como o problema o alcança.

Singleton

Esse padrão é usado quando queremos garantir que exista apenas um de algo. O padrão é realizado impedindo que outros criem nosso objeto.

Wikipedia

MVC

Esse padrão é usado para ajudar a manter as coisas modulares com todos os benefícios que acompanham isso. A Visualização é a "interface do usuário", o Modelo são os dados (incluindo a lógica de negócios) e o Controlador é como as ações do usuário manipulam o modelo. Com essa modularidade, nada me impede de ter várias visualizações / controladores para trabalhar com o mesmo modelo. Para um exemplo excessivamente simplificado, posso interagir com meu email ("modelo") por meio de um site, aplicativo de desktop e meu iPhone ("visualizações + controladores"). Se eu tiver uma caixa de correio de grupo compartilhada, poderia criar um controlador que não enviaria email e reutilizaria a mesma exibição e email do aplicativo. (Sim excessivamente simplista, mas espero que compreensível :))

Além disso, com essa separação bem definida de preocupações, as mudanças em uma (idealmente) não exigem mudanças na outra. Exemplo concreto, se eu precisar dar suporte à leitura / gravação em um banco de dados MySQL em vez de um banco de dados Oracle, eu precisaria apenas mudar meu modelo e minha visão / controlador não será alterada.

Wikipedia

Fábrica

Tenha cuidado aqui, já que existem muitos padrões semelhantes chamados Factory ... Vou falar sobre a Abstract Factory , mas você deve saber que também existe um padrão Factory Method .

Basicamente, eu usaria um Abstract Factory quando souber quais etapas quero executar, mas as etapas de como realizar essas etapas individuais podem variar. Por exemplo, eu poderia estar criando um aplicativo em que preciso criar uma caixa de diálogo com um botão. Ao fazer com que meu código use uma fábrica de interface do usuário hipotética, se eu precisar do meu código no Mac ou Linux em vez do Windows, forneço apenas uma fábrica diferente e o restante do meu código não muda. Para um exemplo potencialmente mais selvagem, eu poderia ter uma Web Factory e, de repente, a maior parte do código que suporta meu aplicativo de desktop agora também está alimentando um site rico :) (ok, impraticável por outros motivos, mas em teoria :))

Para uma criança de 10 anos que quer ser um hacker - eu diria.

Imagine se você pudesse ter alguns dos melhores hackers do mundo ao seu lado, quando você estava hackeando ... e de vez em quando eles diziam .. "você sabe se você faz assim ... [inserir padrão] ... então o código será [mais rápido / seguro / mais sustentável / etc] "quão legal isso seria.

Agora que suponho que ela está interessada na idéia - não perderia meu tempo explicando cada padrão, definiria sua "tarefa de hacking" ... bons recursos e ver para onde vai.

Mas, principalmente, ela precisará aprendê-los por meio de orientação.