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

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

EDITAR: la OO de hoy trata sobre la creación de objetos totalmente independientes cuyas propiedades y habilidades se describen completa / parcialmente mediante diversos métodos (funciones) y atributos (se refiere a las variables y constantes de AKA).

Puedes hablar de conceptos de acoplamiento y cohesión. Los objetos deben estar compuestos de atributos y métodos con alta cohesión y acoplamiento implícitamente alto. 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, la codificación teniendo en cuenta el mantenimiento y la extensibilidad.

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

No me concentraría en los objetos del mundo real, y tampoco me concentraría en los mensajes. Más bien, un ejemplo que he usado es en gráficos, donde desea tener objetos que "saben dibujar ellos mismos".

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

No me gusta referirme a Alan Kay como si fuera Moisés repartiendo las tabletas. Más bien, él fue entrenado en matemáticas y bio, creo. Como matemático, probablemente tenía cierta familiaridad con Lambda Calculus, 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 diferentes cosas 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ía decir que cuando llama a una función (o un método de un objeto) le está enviando un mensaje, y cuando regresa, le está enviando un mensaje a usted (oa su continuación). Esto se estableció como una forma de describir formas de comunicación entre programas que se ejecutan de forma asíncrona en un hardware separado. Eso está bien, pero para la programación ordinaria se está dejando llevar. Para obtener el valor de la idea 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 POO en términos de analogías artificiales lleva a las personas a pensar demasiado en el diseño de software en términos de estructura de datos, lo que lleva a un diseño excesivo, lo que conlleva a una gran cantidad de código y problemas de rendimiento masivos, que tengo que dedicar tiempo a limpiar se pone bastante mal.

Yo afirmarí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 de los gráficos y lo enseñamos con Esfera, cubo, cilindro, es casi lo mismo que usar bola, caja, palo.

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 permanecer allí. Si está haciendo la POO 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. Tome la cuenta bancaria, por ejemplo. Todos "entienden" por qué depositar () y retirar () debe cobrar el cargo por servicio, en lugar de confiar en el código de llamada para cambiar el valor del saldo y recuerde retirar el cargo por servicio. Las formas en una pantalla son doblemente intangibles, y Stroustrup me dijo que el ejemplo clásico de "Formas" es uno de los dos ejemplos más antiguos de OO que conoce, que datan de hace 40 años (el otro es vehículos, ahora tiene 44 años).

Lo importante es que las personas entiendan tus ejemplos de inmediato. Los ascensores son un buen ejemplo solo para las 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 analizar cómo se dirían entre sí para hacer lo que necesita que haga el sistema. Literalmente asuma roles en el sistema (puede hacer esto por su cuenta solo con cada rol, pero es más fácil con un grupo de personas. Los juguetes le ayudan si está solo). Concéntrese en lo que cada persona está haciendo / hará, en lugar de en qué datos tiene. Hacer esto con las personas ayuda a que se centren 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 deben pedirse mutuamente y qué información necesita para hacerlo. Sea protector de sus propios datos, si otro programador le pide 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 los indicadores de estilo C, para mostrar cómo se pueden estructurar los datos en lugar de usar primitivas directamente. Luego explique el enlace tardío y los punteros de función. Luego explique que puede usarlos para construir objetos, que son básicamente pilas de datos bien encapsulados y punteros a las funciones que se necesitan para operar con dichos datos.

Esta explicación contradice la manera convencional de enseñar matemáticamente el concepto independientemente de la implementación, pero es la perspectiva la que me hizo (ciertamente alguien con una ingeniería, no una ciencia comp, antecedentes) finalmente obtengo OO.