¿Cómo podría uno enseñar OO sin hacer referencia a objetos físicos del mundo real? [cerrado]

Recuerdo haber leído en alguna parte que los conceptos originales detrás de OO eran encontrar una mejor arquitectura para manejar la mensajería de datos entre múltiples sistemas de una manera que protegiera el estado de esos datos. Ahora, esa es probablemente una paráfrasis pobre, pero me hizo preguntarme si hay una manera de enseñar OO sin las analogías de objetos (Bicicleta, Coche, Persona, etc.), y eso en cambio se centra en los aspectos de la mensajería. Si tiene artículos, enlaces, libros, etc., eso sería útil.

El concepto original de OO no tiene nada que ver con lo que es hoy OO. (Consulte Entonces, ¿qué * realmente * Alan Kay quiso decir con el término "orientado a objetos"? ). La programación orientada a objetos de hoy es sobre la creación de objetos como las metáforas de bicicletas y casas y personas, etc. Recomiendo encarecidamente seguir con estos porque el propósito de las metáforas es ayudar a las personas a entender usando un concepto que ya entienden. Ayúdelos a ver la correlación y luego ayúdelos a ver las diferencias ENTONCES sumérjase en cosas más profundas sobre OO.

EDITAR: El OO de hoy se trata de crear objetos totalmente autónomos cuyas propiedades y habilidades se describen total / parcialmente utilizando varios métodos (funciones) y atributos (referencias de variables y constantes AKA).

Puedes hablar sobre conceptos de acoplamiento y cohesión. Los objetos deben estar compuestos de atributos y métodos con alta cohesión e implícitamente alto acoplamiento. Deben asignarse a las operaciones y atributos menos granulares necesarios para que el sistema funcione. También deben satisfacer el deseo de mantener el código lo más pequeño y directo posible, es decir, codificar teniendo en cuenta el mantenimiento y la extensibilidad.

Esto también evita la "explosión de objetos", la generalización excesiva y la elección incorrecta de metáforas, que son errores comunes.

No me enfocaría en los objetos del mundo real, y tampoco me enfocaría en los mensajes. Más bien, un ejemplo que he usado es en gráficos, donde desea tener objetos que "sepan cómo dibujarse".

Si está trabajando en C, por ejemplo, que no tiene OO incorporado, puede que le resulte conveniente almacenar punteros a las funciones dentro de los objetos de datos. Si lo haces, entonces estás abriéndote camino hacia OOP.

No me gusta referirme a Alan Kay como si fuera Moisés entregando las tabletas. Más bien, él fue entrenado en matemáticas y bio, creo. Como matemático, probablemente estaba familiarizado con el cálculo Lambda, que era bastante abstracto, no relacionado con el hardware. En LC, podría decir que todo es un "objeto", como el número 0 y el número 1 son objetos que evalúan cosas diferentes cuando se les da un argumento. Eso lleva a Smalltalk bastante bien. La idea de "mensaje" es para que podamos evitar hablar de hardware. Podrías decir que cuando llamas a una función (o un método de un objeto) le estás enviando un mensaje, y cuando regresa, te está enviando un mensaje (o tu continuación). Eso se enganchó como una forma de describir formas de comunicarse entre programas que se ejecutan de forma asíncrona en hardware separado. Esta bien, pero para la programación ordinaria se está dejando llevar. Para obtener el valor de la idea de OOP, no necesita negar la relevancia de la tarea concreta que está tratando de hacer, o negar la concreción del hardware que está ejecutando. Creo que enseñar sobre OOP en términos de analogías artificiales hace que la gente piense demasiado en el diseño de software en términos de estructura de datos, lo que lleva a su sobre diseño, lo que lleva a problemas de código y problemas de rendimiento masivos, que tengo que pasar tiempo limpiando cuando se pone lo suficientemente mal.

Yo diría que hay poca diferencia en usar un objeto físico para un ejemplo y usar un objeto no físico como ejemplo. En el código, ambos tienen exactamente las mismas partes. Si usamos el ejemplo gráfico y lo enseñamos con Esfera, cubo, cilindro, es casi lo mismo que usar bola, caja, poste.

Entonces, para enseñarlo sin usar ejemplos físicos, sugeriría no usar ningún ejemplo en absoluto, pero no veo por qué no querría ejemplos físicos, por lo que mi postura sobre el tema es

No, no deberías enseñarlo sin objetos físicos del mundo real.

No veo cómo puedes evitar comenzar en metáforas del mundo real, pero no quieres quedarte allí. Si está haciendo OOP correctamente, rápidamente se vuelve abstracto, pero en el siguiente nivel de comprensión, el alumno debe comprender los objetos como objetos.

Curiosamente, algunos de mis ejemplos favoritos no son objetos físicos. Tomar cuenta bancaria por ejemplo. Todos "entienden" por qué deposit () y retiran () deberían cobrar el cargo por servicio, en lugar de depender del código de llamada para cambiar el valor del saldo y recordar quitar el cargo por servicio. Las formas en una pantalla son doblemente intangibles, y Stroustrup me dijo que el clásico ejemplo de "Formas" es uno de los dos ejemplos de OO más antiguos que conoce, que data de hace 40 años (el otro son vehículos, ahora de 44 años).

Lo importante es que la gente entienda sus ejemplos de inmediato. Los ascensores son un buen ejemplo solo con personas que están familiarizadas con los ascensores. Etc.

Si está en un grupo de programación, reúna a algunas personas y comience a discutir cómo se dirían unos a otros para hacer lo que necesita que haga el sistema. Literalmente, tome roles en el sistema (puede hacerlo usted solo desempeñando cada rol, pero es más fácil con un grupo de personas. Los juguetes ayudan si está solo). Concéntrese en lo que cada persona está haciendo / hará, en lugar de en qué datos tienen. Hacer esto con las personas ayuda a centrarse en los mensajes y roles porque las personas tienden a recordar lo que están haciendo, pero no los datos que tienen.

Tome nota de lo que tienen que pedirse mutuamente y qué información necesitan para hacerlo. Proteja sus propios datos, si otro programador solicita sus datos para algo, diga no y pregúntele por qué los necesita (ayuda a encapsular los datos).

Creo que un enfoque de abajo hacia arriba / metal podría ser útil. Primero explique las estructuras y punteros de estilo C, para mostrar cómo se pueden estructurar los datos en lugar de simplemente usar primitivas directamente. Luego explique los enlaces tardíos y los punteros de función. Luego explique que puede usarlos para construir objetos, que son básicamente montones de datos bien encapsulados y punteros a las funciones que se necesitan para operar en dichos datos.

Esta explicación contradice la forma convencional de matemáticas / comp. De ciencia de enseñar el concepto independientemente de la implementación, pero es la perspectiva lo que me hizo (ciertamente alguien con un fondo de ingeniería, no de ciencia comp.) Finalmente obtener OO.