Como alguém pode ensinar OO sem fazer referência a objetos físicos do mundo real? [fechadas]

Lembro-me de ler em algum lugar que os conceitos originais por trás do OO eram encontrar uma arquitetura melhor para lidar com o envio de mensagens de dados entre vários sistemas de uma maneira que protegesse o estado desses dados. Agora essa é provavelmente uma paráfrase ruim, mas me fez pensar se há uma maneira de ensinar OO sem as analogias de objeto (Bicicleta, Carro, Pessoa, etc.), e que, em vez disso, foca nos aspectos das mensagens. Se você tiver artigos, links, livros etc., isso seria útil.

O conceito original de OO não tem nada a ver com o que é hoje o OO. (Veja Então, o que * Alan Kay realmente quis dizer com o termo "orientado a objetos"? ). A programação orientada a objetos de hoje é sobre a criação de objetos como as metáforas de bicicletas, casas e pessoas, etc. Eu recomendo ficar com elas porque o objetivo das metáforas é ajudar as pessoas a entenderem usando um conceito que elas já entendem. Ajude-os a ver a correlação e, em seguida, ajude-os a ver as diferenças. ENTÃO mergulhe nas coisas mais profundas sobre OO.

EDIT: O OO de hoje é sobre a criação de objetos totalmente independentes, cujas propriedades e habilidades são totalmente / parcialmente descritas usando vários métodos (funções) e atributos (referencia variáveis ​​e constantes do AKA).

Você pode falar sobre conceitos de acoplamento e coesão. Os objetos devem ser compostos de atributos e métodos com alta coesão e implicitamente alto acoplamento. Eles devem mapear para as operações e atributos menos granulares necessários para o funcionamento do sistema. Eles também devem satisfazer o desejo de manter o código o mais pequeno e direto possível, ou seja, codificando com manutenção e extensibilidade em mente.

Isso também evita "explosão de objetos", generalização excessiva e escolha errada de metáforas, que são erros comuns.

Eu não focaria nos objetos do mundo real e também não focaria nas mensagens. Em vez disso, um exemplo que usei é em gráficos, onde você deseja ter objetos que "sabem como se desenhar".

Se você estiver trabalhando em C, por exemplo, que não tenha OO incorporado, poderá achar conveniente armazenar ponteiros para funções dentro de objetos de dados. Se o fizer, estará entrando no OOP.

Não gosto de me referir a Alan Kay como se ele fosse Moisés entregando as tábuas. Pelo contrário, ele foi treinado em matemática e bio, acredito. Como um cara de matemática, ele provavelmente tinha alguma familiaridade com o Lambda Calculus, que era bastante abstrato, não relacionado ao hardware. Na LC, você pode dizer que tudo é um "objeto" - como o número 0 e o número 1 são objetos que avaliam coisas diferentes quando recebem um argumento. Isso leva ao Smalltalk muito bem. A idéia de "mensagem" é para que possamos evitar falar sobre hardware. Pode-se dizer que, quando você chama uma função (ou o método de um objeto), está enviando uma mensagem e, quando ela retorna, está enviando uma mensagem para você (ou para sua continuação). Isso foi abordado como uma maneira de descrever maneiras de se comunicar entre programas executados de forma assíncrona em hardware separado. Isso é bom, mas para a programação comum está se deixando levar. Para obter o valor da ideia de POO, não é necessário negar a relevância da tarefa concreta que você está tentando executar ou negar a concretude do hardware em que está executando. Eu acho que ensinar sobre OOP em termos de analogias inventadas leva as pessoas a pensar muito em design de software em termos de estrutura de dados, levando ao seu excesso de design, levando a inchaço do código e a problemas de desempenho maciços, que eu tenho que gastar tempo limpando quando fica ruim o suficiente.

Eu diria que há pouca diferença no uso de um objeto físico como exemplo e no uso de um objeto não físico como exemplo. No código, ambos têm exatamente as mesmas partes. Se usarmos o exemplo gráfico e o ensinarmos com Esfera, cubo, cilindro, é quase o mesmo que usar bola, caixa, poste.

Então, para ensiná-lo sem usar exemplos físicos, eu sugeriria não usar nenhum exemplo, mas não vejo por que você não gostaria de exemplos físicos, então minha posição sobre o assunto é

Não, você não deve ensiná-lo sem objetos físicos do mundo real

Não vejo como você pode evitar começar nas metáforas do mundo real, mas não quer ficar lá. Se você está fazendo OOP corretamente, rapidamente se torna abstrato, mas nesse próximo nível de entendimento, o aluno deve entender os objetos como objetos.

Curiosamente, alguns dos meus exemplos favoritos não são objetos físicos. Tome conta bancária, por exemplo. Todos "entendem" por que depositar () e retirar () devem cobrar a taxa de serviço, em vez de depender do código de chamada para alterar o valor do saldo e lembre-se de retirar a taxa de serviço. As formas na tela são duplamente intangíveis, e Stroustrup me disse que o exemplo clássico de "Formas" é um dos dois exemplos mais antigos de OO que ele conhece, com 40 anos (o outro são veículos, agora com 44 anos).

O importante é que as pessoas entendam seus exemplos imediatamente. Os elevadores são um bom exemplo apenas de pessoas familiarizadas com os elevadores. Etc.

Se você estiver em um grupo de programação, reúna algumas pessoas e comece a discutir como se instruiriam para fazer o que você precisa que o sistema faça. Literalmente, assuma papéis no sistema (você pode fazer isso sozinho, apenas desempenhando cada papel, mas é mais fácil com um grupo de pessoas. Os brinquedos ajudam se você estiver por conta própria). Concentre-se no que cada pessoa está fazendo / fará, e não nos dados que ela possui. Fazer isso com as pessoas ajuda a focar nas mensagens e funções, porque as pessoas tendem a lembrar o que estão fazendo, mas não os dados que possuem.

Tome nota do que você deve pedir um ao outro e de quais informações você precisa. Proteja seus próprios dados, se outro programador solicitar algo para seus dados, diga não e pergunte por que ele precisa deles (ajuda no encapsulamento de dados).

Eu acho que uma abordagem de baixo para cima / metal pode ser útil. Primeiro, explique estruturas e ponteiros no estilo C, para mostrar como os dados podem ser estruturados, em vez de apenas usar primitivas diretamente. Em seguida, explique os ponteiros de ligação e função atrasados. Em seguida, explique que você pode usá-los para construir objetos, que são basicamente pilhas de dados e ponteiros bem encapsulados para as funções necessárias para operar com os dados.

Essa explicação contradiz a maneira convencional de matemática / ficção científica de ensinar o conceito independentemente da implementação, mas é a perspectiva que me fez (reconhecidamente alguém com experiência em engenharia, não em ficção científica) finalmente obter OO.