Como explicar os conceitos de POO para uma pessoa não técnica?

Costumo tentar evitar dizer às pessoas que sou programador porque na maioria das vezes acabo explicando o que isso realmente significa. Quando digo a eles que estou programando em Java, eles costumam fazer perguntas gerais sobre a linguagem e como ela difere de xey. Também não sou bom em explicar as coisas porque 1) não tenho muita experiência no campo e 2) odeio explicar as coisas para pessoas não técnicas.

Eles dizem que você realmente entende as coisas depois de explicá-las a outra pessoa. Nesse caso, como você explicaria a terminologia e os conceitos de OOP para uma pessoa não técnica?

Geralmente, tento descrever a programação orientada a objetos usando exemplos do mundo real.

Por exemplo, posso dizer que uma classe chamada Vehicledescreve as coisas mínimas que um veículo é. Vou pedir à pessoa para me dizer o que ela pensa que é um veículo. Às vezes eles dizem coisas como "Bem, como um carro ou um caminhão", e eu aceno e concordo com eles. Então perguntarei quais são as diferenças entre um carro e um caminhão. Algumas vezes mencionam tamanho, outras vezes o propósito e outras coisas.

Depois, peço que eles se esqueçam de um carro ou caminhão e peço que continuem descrevendo um veículo:

"Oh, bem, se move"

"Possui operador ou motorista"

etc ...

Logo, sabemos o que é um Veículo e eu disse que em OOP definiríamos um veículo e, por uma questão de argumento, ele pode se mover e dar a ele um tipo de motorista. Então eu vou perguntar, ok, então o que um carro tem?

"Portas"

"Janelas"

E então um caminhão ....

"Portas" "janelas" "Mais rodas!"

Logo, após muita discussão, a outra pessoa geralmente identificou:

1) O que constitui um veículo

2) O que constitui um carro

3) O que constitui um caminhão

4) O que constitui um avião.

Tudo sem nenhum detalhe técnico. Dividimos as propriedades de cada uma nas áreas corretas. Eles entendem a herança ("Sim, um carro é um veículo, um caminhão é um veículo, mas um carro não é um caminhão, é SIMPLES, duh!").

Eles até entendem o polimorfismo: "Claro, eles basicamente fazem o mesmo, mas isso pode ser um pouco diferente". Podemos falar sobre comportamento e onde isso deve estar na nossa árvore de objetos.

Dependendo da sua formação e formação, alguns conseguem mais rápido que outros. Mas quando eu comparo OOP a objetos da vida real, a maioria das pessoas sempre o entende. De fato, encontrei em conversas com pessoas não técnicas coisas em que nunca havia pensado. Os veículos não precisam ser tripulados, por exemplo (drones), mas um programador teria pensado no operador do veículo como uma propriedade dele? Não estou dizendo que é certo ou errado mencionar um operador, mas isso nos leva a pensar sobre o que estamos modelando e o que estamos tentando alcançar quando desenvolvemos software.

Agora, especialização parcial de modelos, por outro lado .... :)

Objetos são substantivos, métodos são verbos.

Aqui está uma versão da minha resposta enlatada que dou à pessoa ultra não técnica:

A programação é uma tentativa de criar uma representação da realidade no computador. Já existem muitas ferramentas e dispositivos que fazem isso - pense em como uma planilha nos facilita representar representações contábeis ou estatísticas ou como uma apresentação do Powerpoint nos permite armazenar e exibir nossas apresentações.

Às vezes, precisamos criar representações personalizadas da realidade em aplicativos novos ou existentes que refletem nossos processos de negócios. Existem várias maneiras de programar, e uma das maneiras mais comuns de programar é a programação orientada a objetos, onde o código que construímos é projetado especificamente para replicar os conceitos de realidade. As "coisas" na realidade têm atributos e comportamentos. Por exemplo, um ser humano geralmente possui braços e pernas, cor de cabelo, etnia e pode falar e andar.

Falar e andar podem ter diferentes variedades, como o idioma em que se está falando ou a velocidade ou maneira com que se está andando.

Os seres humanos costumam ter interações com outros tipos de "coisas", sejam animais, outros seres humanos, outros organismos vivos ou objetos inanimados. Na realidade, existem temas que geralmente precisam de uma maneira de serem representados, como interações entre "coisas", categorização de coisas, etc. Considere os processos de negócios que ocorrem em nossa organização. Existe uma "lógica de negócios" muito complicada que precisa ser representada no software que nossa organização usa.

A programação orientada a objetos fornece um meio de representar com precisão esses "conceitos do mundo real" e "lógica de negócios".

-> Essa afirmação geralmente é suficiente para afastar sua curiosidade (ou talvez as aborreça), mas se elas tiverem mais perguntas, a afirmação acima (acredito) estabelece uma base decente para onde a conversa pode ir. Eu realmente não acho que a pessoa não técnica se preocupe muito com terminologia técnica como "Abstração", "Composição", "Polimorfismo" etc. etc. para puxar exemplos baseados nele.

Eu sempre aprendi OOP assim:

Você tem um relógio, e isso indica o tempo - bem, na programação, você coloca todo o código e tudo o que precisa fazer juntos (parece bastante óbvio, mas as pessoas não costumavam fazer isso dessa maneira nos primeiros dias). Enfim, isso é chamado de encapsulamento .

Agora que você tem um relógio, você pode querer um despertador - bem, depois de reunir todas as coisas, você pode adicionar coisas para fazer mais - como definir o alarme e tocar. Isso é chamado de herança .

Além disso, você olha para o relógio que tenho no meu pulso, mas pode ver outros relógios que parecem diferentes como um relógio de ponto ou um relógio digital. Parece diferente, mas ainda é um relógio - bem, isso se chama polimorfismo .

E aí você tem os três cantos da programação orientada a objetos. Todo o resto é apenas codificação.

Eu apenas diria a eles para se inscreverem em um curso no OOP, se realmente quiserem entender.

Quero dizer, todas essas analogias como Car.startEngine (); são, vamos enfrentá-lo - puro rap. Quando entrei na OOP há muitos anos, descobri que eles apenas abstraem ainda mais o domínio.

Em vez de apenas explicar que OOP é sobre o gerenciamento da complexidade de linguagens procedurais, quase 80% dos autores de livros de programação assumem que os programadores são idiotas sem noção que precisam ser falados em termos simples (veja a ironia aqui?).

Sim, é perfeitamente normal explicar as Listas e os Vetores, porque é com isso que trabalhamos principalmente, não Car.Engine e PoliceMan.Arrest (a menos que você seja um desenvolvedor de jogos, mas, novamente, você ainda deve ter sua parte do antigo).

Voltando ao tópico, eu apenas diria a eles, crio objetos intangíveis que existem puramente na mente do programador, com a finalidade de processamento de folha de pagamento / jogo / navegação com ônibus espacial, etc.

Se eles ainda tiverem perguntas, pare de discutir, porque não vale a pena. A maioria das pessoas falha em imaginar noções abstratas e precisa de exemplos para quase tudo (o que significa mais simplificação / especialização do tópico real).

Conversei sobre uma conversa que tive com minha esposa sobre isso, nesta resposta aqui: /software/45464/how-to-convince-non-programmer-his-notions-about- computadores estão errados / 45467 # 45467

Edição: A pergunta que eu respondi lá foi moderada, por isso vou repetir minha resposta aqui.

Sentada em um restaurante com minha esposa, ela me perguntou: "O que significa Orientação a Objetos?"

Comecei a falar sobre reutilização de código, encapsulamento e polimorfismo, e em algum momento percebi que os olhos dela estavam com um brilho terminal.

Então peguei um pacote Splenda fora do contêiner. Eu disse: "Aqui está um objeto. Quais são suas propriedades?"

Ela disse: "É retangular, é feita de papel, contém esplêndidos, é azul, tem impressão".

Peguei um pacote de açúcar. "O que isso tem em comum com este?"

Ela disse: "A retangularidade, o papel, que há impressão".

Eu disse: "Que tal os dois conterem algo doce?"

Ela disse: "Claro".

Eu disse: "Portanto, esses são dois exemplos do que podemos chamar de pacote adoçante abstrato. Um pacote adoçante ideal platônico, se você quiser".

Ela disse: "Claro".

Eu disse: "E cada um tem propriedades herdadas do pacote abstrato e, em seguida, variações daquelas que são específicas ao seu tipo de coisa".

Ela disse: "Certo. Ah! E se eu quisesse fazer, tipo, um pacote Saccharine, pegaria o genérico e definiria os detalhes para o Saccharine, e então eu o teria!"

Eu disse: "Bingo: Programação Orientada a Objetos".

Você e eu sabemos que ela acabou de intuir o caminho para o padrão de design da Factory. Tanto faz. Ilustra herança, encapsulamento, identidade de classe de objeto ... Coisas boas.

Esta questão parece candidata a ser encerrada, no entanto ...

Como a maioria das coisas, o POO é realmente muito simples de explicar em um nível conceitual. Programadores modelam objetos; e:

• objetos têm estado (campos / membros de dados)
• objetos têm ações (métodos / funções)
• objetos construídos um sobre o outro (herança)

São centenas de detalhes, com certeza. Mas se você está apenas tentando dar a alguém a visão geral de 10 segundos, acho que é um bom começo. Existem conceitos mais específicos que você está tendo problemas para explicar?

O exemplo do telefone móvel:

Imagine que você é proprietário de uma fábrica, deseja descrever um telefone genérico

• Etapa 1: liste as propriedades deste telefone genérico, por exemplo: altura, peso, cor etc.
• Passo 2: Listar as funções deste telefone genérico , por exemplo: fazer chamadas, receber chamadas, enviar sms etc.

Agora que você tem o seu "modelo" genérico, crie-me os seguintes telefones:

Telefone 1:

• Altura-> 102mm

• Peso-> 85g

• Cor-> Rosa

Telefone 2:

• Altura-> 125mm

• Peso-> 96g

• Cor-> Vermelho

Eu acho que a melhor maneira de explicar a um tipo não técnico sobre OOP é relacioná-lo a eles.

Essencialmente, OOD e OOP querem que você pense no sistema que está projetando e implementando como um mundo de coisas em interação.

Então vamos, por uma questão de argumentação (que nunca sai bem na internet), digamos que você esteja explicando a um coletor de lixo sobre OOD & P. O nome dele é Bob. Você costumava ir à escola com ele há 15 anos, esbarrou com ele em um bar e ambos estão fingindo interesse na vida um do outro.

"Então, John, você diz que é programador. Meu sobrinho gosta de toda essa bobagem. Continua falando sobre programação orientada a objetos, ou algo assim. O que é isso tudo?" Observe que Bob é britânico pela maneira como ele escreve incorretamente.

"Bem, Bob", você responde, encolhendo-se na orientação. "É bem simples, na verdade. Você coleta lixo, certo? O que geralmente você faz no seu trabalho?"

"Bem, eu sigo a van pela cidade pegando lixo e colocando na van", responde Bob, intrigado.

e você precisará ouvir isso. Esses são os nossos comportamentos. Isso é basicamente tudo o que você precisa para o design. A programação orientada a objetos é essencialmente como você implementa o design. Difere de idioma para idioma ".

Bob adormeceu em sua cerveja. Você vai embora.

Gosto do exemplo do carro para explicar a herança (eu costumo usar animais em vez de veículos, mas é a mesma ideia), mas para explicar como funciona um programa orientado a objetos, refiro-me a uma analogia que li uma vez no site de Chris Crawford: o programa é como uma burocracia realmente eficiente. Todos os diferentes objetos do programa são como os diferentes departamentos de uma burocracia; cada departamento tem suas próprias tarefas designadas, possui entradas bem definidas (com quem conversar e quais formulários preencher) e outros departamentos geralmente não sabem muito sobre o que acontece lá dentro. O RH é como uma fábrica abstrata, a TI é um singleton etc.

Receber uma mensagem de erro porque você digitou a coisa errada em um programa de computador é exatamente como preencher o formulário errado para enviar para um escritório.

OOP é uma simplificação grosseira, se é que existe alguma coisa - uma abstração - do processo de pensamento humano e da compreensão do mundo para projetar a funcionalidade em um "vazio" digital para imitar processos e classificações familiares digitalmente. É, em muitos aspectos, mais sobre o nosso estado de linguagem primitiva do que nós "pensando mais como computadores".

Se a programação imitasse a realidade ou o pensamento humano, seria muito mais orgânico, caótico e aleatório na natureza - até lateral. Em vez disso, simplificamos a realidade em pequenos passos, "lógica 2 + 2", categorias grosseiras, pequenas ferramentas reutilizáveis ​​e raciocínio pré-histórico.

Ainda estamos tentando descobrir como baixar nossos pensamentos e desejos em um protocolo e linguagem comum, e eu acho que os historiadores ficarão fascinados com sua sofisticação grosseira um dia - como agora vemos hieróglifos. Não é nada "inteligente" - simplesmente destaca como não podemos explicar facilmente como decidimos ou entendemos até as coisas mais simples. A computação ainda está no nível de evolução do pensamento "um cachorro é um cachorro porque não é um gato" - está milênios atrás da linguagem falada básica.

Existem dois tipos de assistentes. Há o cara que faz coisas específicas acontecerem com palavras mágicas. Ele tem uma palavra para convocar fogo. Ele tem uma palavra para fazer uma galinha congelada aparecer do nada. E outra palavra para criar um pote de força (eu prefiro minha força verde, brilhante e translúcida) cheia de bondade friolante. Com a aplicação correta de suas palavras, ele pode produzir um frango frito.

E depois há o assistente OOP. Quem acaba de convocar um diabinho que sabe ir ao supermercado, comprar uma galinha (ou ingredientes para qualquer outro alimento que você queira que ele prepare), cozinhar e servir o jantar. OOP Wizard não precisa dizer ao seu imp como fazê-lo. Ele só precisa que ele saiba o que quer, que neste caso é frango frito. Não é só isso, o mago OOP pode convocar outros lacaios para dizer ao seu chefe de cozinha o que fazer.

Então, o cara de encantamento impressiona nas festas, mas o assistente de POO é o que você deseja quando você vai começar um restaurante mágico com um monte de personagens (como, por exemplo, um garçom unicórnio irritado e um gerente de andar de troll) que todos tem que trabalhar juntos. Se você tentar invocar todas as etapas do problema de resolver "restaurante", poderá facilmente se envolver nos detalhes e é muito fácil cometer erros. O assistente de POO pré-treina seus subordinados para resolver os detalhes para ele, para que ele possa se concentrar em resolver o problema maior fazendo com que seu pessoal interaja.

Sem mencionar que é mais fácil reutilizar seu chef-imp para o seu problema no refeitório da escola primária, é separar todo o lixo que você pode ou não reutilizar quando está fazendo tudo isso, um passo de cada vez, chamando palavras e palavras que chamam outros conjuntos de palavras (que serão cada vez mais numerosas quando você precisar lidar com uma variedade maior de problemas).

Para ser justo, com uma aplicação muito, muito cuidadosa, o assistente de encantamento pode fazer tudo tão rápido quanto o assistente de POO. Ele pode dividir as coisas da maneira correta, de modo que invocar as magias certas não exija mais trabalho de sua parte do que o assistente de OOP. Mas o trabalho é muito mais difícil de entender ou duplicar e muito mais difícil reutilizar grandes porções, porque está tudo interligado para um problema complexo específico.