¿Cómo explicar los conceptos de OOP a una persona no técnica?

A menudo trato de evitar decirle a la gente que soy programador porque la mayoría de las veces termino explicándoles lo que realmente significa. Cuando les digo que estoy programando en Java, a menudo hacen preguntas generales sobre el lenguaje y cómo difiere de x e y. Tampoco soy bueno para explicar las cosas porque 1) no tengo mucha experiencia en el campo y 2) Realmente odio explicar las cosas a personas no técnicas.

Dicen que realmente comprende las cosas una vez que se las explica a otra persona, en este caso, ¿cómo explicaría la terminología y los conceptos de OOP a una persona no técnica?

Generalmente trato de describir la Programación Orientada a Objetos usando ejemplos del mundo real.

Por ejemplo, podría decir que una clase llamada Vehicledescribe las cosas mínimas que es un vehículo. Le pediré a la persona que me diga qué cree que es un vehículo. A veces dicen cosas como "Bueno, como un automóvil o un camión", y yo asentiré y estaré de acuerdo con ellos. Luego preguntaré cuáles son las diferencias entre un automóvil y un camión. A veces mencionan el tamaño, a veces el propósito y otras cosas.

Luego les pediré que se olviden de un automóvil o un camión y simplemente les pediré que continúen describiendo un vehículo:

"Oh, bueno, se mueve"

"Tiene un operador o un conductor"

etc ...

Pronto, sabemos lo que es un Vehículo y dije que en OOP definiríamos un vehículo, y por el simple hecho de decir que puede moverse, y le daríamos un tipo de conductor. Entonces preguntaré, ok, ¿qué tiene un auto?

"Puertas"

"Windows"

Y luego un camión ...

"Puertas" "ventanas" "¡Más ruedas!"

Pronto, después de mucha discusión, la otra persona generalmente ha identificado:

1) Qué constituye un vehículo

2) Qué constituye un automóvil

3) Qué constituye un camión

4) Qué constituye un avión.

Todo sin tecnicismos. Hemos dividido las propiedades de cada uno en las áreas correctas. Entienden la herencia ("Sí, un automóvil es un vehículo, un camión es un vehículo, pero un automóvil no es un camión, ¡es SIMPLE, duh!").

Incluso entienden el polimorfismo, "Claro, básicamente hacen lo mismo, pero eso podría hacerlo un poco diferente". Podemos hablar sobre el comportamiento y dónde debería vivir en nuestro árbol de objetos.

Dependiendo de su educación y antecedentes, algunos lo obtienen más rápido que otros. Pero cuando comparo OOP con objetos de la vida real, la mayoría de las personas siempre lo entienden. De hecho, he encontrado en conversaciones con personas no técnicas cosas en las que nunca había pensado. Los vehículos no tienen que ser tripulados, por ejemplo (drones), pero ¿un programador habría pensado que el operador del vehículo es una propiedad del mismo? No digo que sea correcto o incorrecto que se mencione un operador, pero nos hace pensar en lo que estamos modelando y lo que estamos tratando de lograr cuando desarrollamos software.

Ahora, especialización parcial de plantilla, por otro lado .... :)

Los objetos son sustantivos, los métodos son verbos.

Aquí hay una versión de mi respuesta enlatada que le doy a la persona ultra no técnica:

La programación es un intento de crear una representación de la realidad en la computadora. Ya existen muchas herramientas y dispositivos que hacen esto: piense en cómo una hoja de cálculo nos facilita representar la contabilidad o las estadísticas, o cómo una presentación de Powerpoint nos permite almacenar y mostrar nuestras presentaciones.

A veces necesitamos construir representaciones personalizadas de la realidad en aplicaciones nuevas o existentes que reflejen nuestros procesos comerciales. Hay muchas formas de programar, y una de las formas más comunes de programar es la programación orientada a objetos, donde el código que creamos está específicamente diseñado para replicar los conceptos de realidad. Las "cosas" en realidad tienen atributos y comportamientos. Por ejemplo, un ser humano a menudo tiene brazos y piernas, color de cabello, origen étnico y a menudo puede hablar y caminar.

Hablar y caminar puede venir en diferentes variedades, como el idioma que se habla o la velocidad o la forma en que se camina.

Los seres humanos a menudo tienen interacciones con otros tipos de "cosas", ya sean animales, otros humanos, otros organismos vivos u objetos inanimados. En realidad, hay temas que a menudo necesitan una forma de ser representados, como las interacciones entre "cosas", la categorización de las cosas, etc. Considere los procesos comerciales que tienen lugar en nuestra organización. Existe una "lógica de negocios" muy complicada que necesita ser representada en el software que utiliza nuestra organización.

La programación orientada a objetos proporciona un medio para representar con precisión estos "conceptos del mundo real" y la "lógica empresarial".

-> Esta declaración suele ser suficiente para evitar su curiosidad (o tal vez los aburre hasta las lágrimas), pero si tienen más preguntas, la declaración anterior (creo) establece una base decente sobre hacia dónde puede llegar la conversación. Realmente no creo que la persona no técnica se preocupe demasiado por la terminología técnica como "Abstracción", "Composición", "Polimorfismo", etc., pero si lo son, el lenguaje que utilicé en la declaración enlatada me permite para sacar ejemplos basados ​​en ello.

Siempre aprendí POO así:

Tienes un reloj y te dice la hora, bueno, en la programación pones todo el código y todo lo que tienes que hacer (suena bastante obvio, pero la gente no solía hacerlo en los primeros días). De todos modos, eso se llama encapsulación .

Ahora que tiene una cosa de reloj, es posible que desee una alarma, bueno, una vez que tenga todo junto, puede agregarle cosas para que haga más, como configurar la alarma y hacer que suene. Esto se llama herencia .

Además, miras el reloj que tengo en mi muñeca, pero puedes ver otros relojes que se ven diferentes, como un reloj de pared o un reloj digital. Parece diferente, pero sigue siendo un reloj, bueno, eso se llama polimorfismo .

Y ahí tienes las 3 esquinas de la programación orientada a objetos. Todo lo demás es solo codificación.

Simplemente les diría que se inscriban en un curso en OOP si realmente quieren entenderlo.

Quiero decir, todas esas analogías como Car.startEngine (); somos, seamos sinceros, puro rap. Cuando estuve por primera vez en OOP hace muchos años, descubrí que solo abstraían el dominio aún más.

En lugar de simplemente explicar que OOP se trata de manejar la complejidad de los lenguajes de procedimiento, casi el 80% de los autores de libros de programación asume que los programadores son idiotas sin idea que necesitan ser hablados en términos simples (¿ven la ironía aquí?).

Sí, es perfectamente normal seguir explicando Listas y Vectores, porque eso es con lo que trabajamos principalmente, no con Car.Engine y PoliceMan. ex).

Volviendo al tema, solo les diría que creo objetos intangibles que existen exclusivamente en la mente del programador, con el propósito de procesar la nómina / juego / navegación del transbordador espacial, etc.

Si todavía tienen preguntas, deja de discutir, porque no vale la pena. La mayoría de las personas no logran imaginar nociones abstractas y necesitan ejemplos para casi todo (lo que significa más simplificación / especialización del tema real, en realidad).

Hablé sobre una conversación que tuve con mi esposa sobre esto mismo, en esta respuesta aquí: /software/45464/how-to-convince-non-programmer-his-notions-about- las computadoras están mal / 45467 # 45467

EDITAR: La pregunta que respondí allí fue moderada, así que repetiré mi respuesta aquí.

Sentada en un restaurante con mi esposa, ella me preguntó "¿Qué significa orientado a objetos?"

Comencé a pensar en la reutilización de códigos, la encapsulación y el polimorfismo, y en algún momento me di cuenta de que sus ojos estaban vidriosos.

Así que tomé un paquete de Splenda del contenedor. Le dije: "Aquí hay un objeto. ¿Cuáles son sus propiedades?"

Ella dijo: "Es rectangular, está hecha de papel, contiene esplenda, es azul, tiene una impresión".

Recogí un paquete de azúcar. "¿Qué tiene en común con este?"

Ella dijo: "La rectangularidad, el papel, que hay impresión".

Le dije: "¿Qué hay de que ambos contienen algo dulce?"

Ella dijo: "Claro".

Dije: "Así que estos son dos ejemplos de lo que podríamos llamar un paquete de edulcorante abstracto. Un paquete de edulcorante ideal platónico, si lo desea".

Ella dijo: "Claro".

Dije: "Y cada uno tiene propiedades heredadas del paquete abstracto, y luego variaciones sobre eso que son específicas de su tipo de cosas".

Ella dijo: "Correcto. ¡Oh! ¡Y si quisiera hacer, como, un paquete de sacarina, tomaría el genérico, y establecería los detalles para la sacarina, y luego tendría eso!"

Le dije: "Bingo: programación orientada a objetos".

Tú y yo sabemos que ella acaba de intuir su camino hacia el patrón de diseño Factory. Lo que sea. Ilustra herencia, encapsulación, identidad de clase de objeto ... Cosas buenas.

Esta pregunta parece un candidato para ser cerrada, sin embargo ...

Como la mayoría de las cosas, OOP es realmente muy simple de explicar a nivel conceptual. Los programadores modelan objetos; y:

• los objetos tienen estado (campos / miembros de datos)
• los objetos tienen acciones (métodos / funciones)
• objetos construidos uno sobre el otro (herencia)

Estos son cientos de detalles más finos, claro. Pero si solo estás tratando de darle a alguien la visión general de 10 segundos, creo que es un buen comienzo. ¿Hay más conceptos específicos que tienes problemas para explicar?

El ejemplo del teléfono móvil:

Imagina que eres dueño de una fábrica, quieres describir un teléfono genérico

• Paso 1: enumere las propiedades de estos teléfonos genéricos , por ejemplo: altura, peso, color, etc.
• Paso 2: enumere las funciones genéricas de este teléfono , por ejemplo: hacer una llamada, recibir una llamada, enviar un SMS, etc.

Ahora que tiene su "modelo" genérico, créame los siguientes teléfonos:

Teléfono 1:

• Altura-> 102 mm

• Peso-> 85g

• Color-> Rosa

Teléfono 2:

• Altura-> 125 mm

• Peso-> 96g

• Color-> Rojo

Creo que la mejor manera de explicar a un tipo no técnico acerca de OOP es relacionarlo con ellos.

Esencialmente, OOD & OOP quiere que pienses en el sistema que estás diseñando e implementando como un mundo de cosas interactivas.

Entonces, en aras de la discusión (que nunca funciona bien en Internet), digamos que le estás explicando a un recolector de basura sobre OOD & P. Su nombre es Bob. Solías ir a la escuela con él hace 15 años, te has topado con él en un bar y ambos fingen interés en la vida del otro.

"Entonces, John, dices que eres un programador. A mi sobrino le gustan todas esas tonterías. Sigue hablando de programación orientada a objetos, o algo así. ¿De qué va todo eso?" Tenga en cuenta que Bob es británico por la forma en que se orienta mal.

"Bueno, Bob", respondes, encogiéndote en la orientación. "Es bastante simple en realidad. Recolecta basura, ¿verdad? ¿Qué, en general, haces en tu trabajo?"

"Bueno, sigo la camioneta por la ciudad recogiendo basura y poniéndola en la camioneta", responde Bob, con curiosidad.

y tendrás que escuchar eso. Esos son nuestros comportamientos. Eso es esencialmente todo lo que necesitas para el diseño. La programación orientada a objetos es esencialmente cómo implementa el diseño. Difiere de un idioma a otro ".

Bob se ha quedado dormido en su cerveza. Te alejas.

Me gusta el ejemplo del automóvil para explicar la herencia (tiendo a usar animales en lugar de vehículos, pero es la misma idea), pero para explicar cómo funciona un programa orientado a objetos, me refiero a una analogía que una vez leí en el sitio web de Chris Crawford: el programa es como Una burocracia realmente eficiente. Todos los diferentes objetos en el programa son como los diferentes departamentos en una burocracia; cada departamento tiene sus propias tareas designadas, tienen entradas bien definidas (con quién hablar y qué formularios completar), y otros departamentos a menudo no saben mucho sobre lo que sucede dentro. RRHH es como una fábrica abstracta, IT es un singleton, etc.

Recibir un mensaje de error porque escribió algo incorrecto en un programa de computadora es exactamente como completar el formulario incorrectamente para enviarlo a una oficina.

OOP es una gran simplificación en todo caso, una abstracción, del proceso de pensamiento humano y la comprensión del mundo para proyectar la funcionalidad en un "vacío" digital para imitar digitalmente procesos y clasificaciones familiares. Es, en muchos aspectos, más sobre nuestro estado de lenguaje primitivo que nosotros "pensando más como computadoras".

Si la programación imitara la realidad o el pensamiento humano, sería mucho más orgánico, caótico y desordenado en su naturaleza, incluso lateral. En cambio, simplificamos la realidad en pequeños pasos, "lógica 2 + 2", categorías crudas, pequeñas herramientas reutilizables y razonamiento prehistórico.

Todavía estamos tratando de encontrar la manera de descargar nuestros pensamientos y deseos en un protocolo y un lenguaje común, y creo que los historiadores estarán fascinados con su crudeza sofisticada algún día, como ahora vemos jeroglíficos. No es "inteligente" en absoluto: simplemente destaca cómo no podemos explicar fácilmente cómo decidimos o entendemos incluso las cosas más simples. La informática todavía está en el nivel de evolución del pensamiento "un perro es un perro porque no es un gato", está milenios atrás incluso del lenguaje hablado básico.

Hay dos tipos de magos. Está el tipo que hace que sucedan cosas específicas con palabras mágicas. Tiene una palabra para invocar fuego. Tiene una palabra para hacer que un pollo congelado aparezca de la nada. Y otra palabra para crear una olla de fuerza (prefiero mi fuerza verde, brillante y translúcida) llena de bondad frioladora. Con la correcta aplicación de sus palabras, puede producir un pollo frito.

Y luego está el asistente de OOP. Quien simplemente convoca a un diablillo que sabe cómo ir al supermercado, comprar un pollo (o ingredientes para cualquier otro alimento que desee que prepare), cocinarlo y servirle la cena. OOP Wizard no tiene que decirle a su diablillo cómo hacerlo. Solo necesita hacerle saber lo que quiere, que en este caso es pollo frito. No solo eso, el asistente de OOP puede convocar a otros secuaces para decirle a su imp-chef qué hacer.

Entonces, el tipo de encantamiento impresiona en las fiestas, pero el asistente de OOP es el que deseas cuando vas a comenzar un restaurante mágico con un montón de personajes (como, por ejemplo, un camarero unicornio enojado y un gerente de piso de trol) que todos tienen que trabajar juntos Si intenta invocar cada paso del problema de resolver el "restaurante", puede enredarse fácilmente en los detalles y es muy fácil cometer errores. El asistente de OOP pre-entrena a sus secuaces para ordenar los detalles para él, de modo que pueda concentrarse en resolver el problema más grande haciendo que su gente interactúe.

Sin mencionar que es más fácil reutilizar su imp-chef para el problema de la cafetería de su escuela primaria, entonces es separar toda la basura que pueda o no reutilizar cuando lo hace paso a paso llamando palabras y palabras que llaman a otros conjuntos de palabras (que se volverán más numerosas a medida que tenga que manejar una mayor variedad de problemas).

Para ser justos, con una aplicación muy cuidadosa, el asistente de encantamiento puede hacerlo todo tan rápido como el asistente de OOP. Puede desglosar las cosas de la manera correcta, de modo que invocar los hechizos correctos no requiere más trabajo de su parte que el mago OOP. Pero el trabajo es mucho más difícil de entender o duplicar y mucho más difícil de reutilizar porque grandes partes están unidas para un problema complejo específico.