¿La programación orientada a objetos realmente modela el mundo real? [cerrado]

He visto que se repite comúnmente que la programación orientada a objetos se basa en modelar el mundo real, pero ¿no es así?

Me parece que eso no es cierto para nada fuera de la capa empresarial. Mis clases de GUI / clases de acceso a datos no están modelando nada en el mundo real. Incluso en mi capa empresarial, tengo clases como observadores, gerentes, fábricas, etc. que no son objetos del mundo real. Intento diseñar mis clases para aprovechar cosas como la encapsulación, pero ¿está encapsulado el mundo real?

Si bien algunos objetos que creo están modelando objetos del mundo real, ¿no haría lo mismo el código anterior a OOP? Dudo que OO haya sido la primera persona en incluir conceptos como Cliente en sus bases de código. Pero OO realmente trata sobre cómo modelar cosas, y ese método de modelado no me parece inspirado por el mundo real.

Entonces: ¿la programación orientada a objetos realmente modela el mundo real?

No, en absoluto.

Sin embargo, es una metodología que permite crear una buena abstracción para mantener estructuras de datos complejas junto con algunos métodos que actúan sobre las estructuras de datos.

Los modelos, de cualquier tipo, no modelan el mundo real, no del todo.

Modelan seleccionados porciones, los que son relevantes para la aplicación a mano.

De lo que está hablando (observadores, gerentes, fábricas, etc.) es una infraestructura que está allí para ayudarlo a obtener la abstracción correcta y respaldar las funciones requeridas, como la persistencia.

De todos modos, qué es un modelo:
un modelo es una representación simplificada que se utiliza para explicar el funcionamiento de un sistema o evento del mundo real.

¿La programación orientada a objetos le permite modelar el mundo real?

Definitivamente sí

Es casi imposible modelar el sistema para que coincida exactamente con el mundo real.

¿Siempre tengo que modelar el software exactamente según el mundo real?

NO

Habiendo dicho que puedes modelar todo no significa que tengas que modelar todo. De hecho, la esencia del modelado útil es presentar una representación simplificada. La cantidad de simplificación es suficiente para expresar la necesidad comercial actual y lo que debe omitirse es un buen equilibrio entre usar la técnica con éxito y perderse con ella o no usarla en absoluto.

Por supuesto, hay entidades que no existen realmente, pero solo a través del modelado podemos conceptualizar bien.

Creo que enseñar que existe una relación entre los sustantivos y las clases hace que se desarrollen malos hábitos molestos que un arquitecto impaciente o un ingeniero superior deben eliminar más adelante.

Lo que debe enseñarse es que las clases modelan objetos abstractos, tal como lo hace su cerebro. Tiene un concepto abstracto de "automóvil" en su cabeza que no se asigna a ningún automóvil físico en particular, es reutilizable, las implementaciones específicas del automóvil pueden heredar de él. Su cerebro incluso modela conceptos para usted. Tienes un modelo mental de lo que es el pensamiento, lo que es un concepto.

Si enseñáramos a las personas a identificar los modelos que ya están generando en su cabeza, estarían mucho mejor preparados para construir software real.

... El mundo es más rico de lo que se puede expresar con sintaxis orientada a objetos.

Considere algunos conceptos comunes que las personas usan universalmente para comprender y describir todos los sistemas, conceptos que no se ajustan al molde del objeto. El paradigma 'antes / después', así como el de 'causa / efecto', y la noción del 'estado del sistema' se encuentran entre los ejemplos más vívidos. De hecho, el proceso de 'preparar café', o 'armar un vehículo', o 'aterrizar un rover en Marte' no puede descomponerse en objetos simples. Sí, están siendo tratados de esa manera en los lenguajes OO, pero eso es artificial y contrario a la intuición. La secuencia de la rutina en sí misma, lo que viene antes de qué y en qué condiciones en función de qué causalidad, simplemente no tiene una representación significativa en OO , porque OO no tiene un concepto de secuenciación, estado o causa.

Los procesos son extremadamente comunes en el mundo real y en la programación. Se han ideado mecanismos elaborados a lo largo de los años para manejar transacciones, flujo de trabajo, orquestación, hilos, protocolos y otros conceptos inherentemente 'procesales'. Esos mecanismos generan complejidad a medida que intentan compensar la deficiencia inherente al tiempo inherente en la programación OO. En cambio, el problema debe abordarse desde la raíz permitiendo que las construcciones específicas del proceso, como 'antes / después', 'causa / efecto' y, tal vez, 'estado del sistema' sean una parte central del lenguaje ...

fuente de la cita: Victoria Livschitz, The Next Move in Programming

Sí, OO a menudo se puede usar para modelar entidades del mundo real.

Incluso en mi capa empresarial tengo clases como observadores, gerentes, fábricas, etc. que no son objetos del mundo real.

No confunda el desarrollo orientado a objetos con patrones de diseño. El análisis y diseño de OO es un medio para acercarse a la programación de código mantenible. Junto con un lenguaje OO, los programadores tienen el poder de crear código reutilizable a través de los pilares de OO: encapsulación, polimorfismo y herencia.

Para encapsular una entidad, podemos modelar esa entidad después de su contraparte en el mundo real. Por ejemplo, si tenemos una guitarra, una clase de guitarra encapsula los comportamientos y las propiedades de una guitarra del mundo real. Podemos abstraer aún más la guitarra como, por ejemplo, una IInventoryItempara aprovechar el potencial de reutilización del código a través del polimorfismo y la herencia.

Por otro lado, podemos encontrar que una fábrica de guitarras podría ayudarnos a mantener un conjunto de diferentes tipos de guitarras. Esto no es por OO. Más bien, una fábrica es un patrón de diseño que ha resistido la prueba del tiempo como un medio probado de crear con éxito un código de mantenimiento para tal fin. En otras palabras, los programadores a menudo estamos resolviendo problemas similares. Así que se nos ocurrió una solución común para resolverlos (no reinventar la rueda).

Eso no significa que OO tenga que modelar el mundo real, ni que siempre sea la solución más óptima para hacerlo. Simplemente, como regla general, "OO modelando el mundo real" tiene mucho sentido.

Depende del mundo real del que estés hablando.

Jorge Luis Borges escribió una historia "Tlön, Uqbar, Orbis Tertius", donde uno de los pueblos habitantes parece percibir su mundo real de manera muy diferente:

[...] la gente del imaginario Tlön [...] posee una forma extrema de idealismo berkeleiano, negando la realidad del mundo. Su mundo se entiende "no como una concurrencia de objetos en el espacio, sino como una serie heterogénea de actos independientes". Una de las lenguas imaginadas de Tlön carece de sustantivos. Sus unidades centrales son "verbos impersonales calificados por sufijos o prefijos monosilábicos que tienen la fuerza de los adverbios". Borges enumera un equivalente tlönic de "La luna se elevó sobre el agua": hlör u fang axaxaxas mlö, que significa literalmente "Hacia arriba detrás de la corriente en la que estuvo en la luna". [...] En otro idioma de Tlön, "la unidad básica no es el verbo, sino el adjetivo monosilábico", que, en combinaciones de dos o más, forma un sustantivo: "luna" se convierte en "luz circular redonda" oscuro "o"

(copiado de la wikipedia artice sobre el libro)

Para mí, el punto no es tanto que el mundo pueda ser percibido de manera diferente a como lo hacemos nosotros, lo cual es un poco cliché, sino que la percepción de la estructura de la realidad misma depende del lenguaje que hablemos, ya sea un lenguaje natural o de programación. El Tlönese podría estar muy contento con Lisp, y podría ver Java (AKA The Kingdom Of Nouns ) como muy poco natural, mientras que la mayoría de los programadores terran tienden a favorecer la orientación a objetos en lugar de lenguajes funcionales. Me gustan ambos estilos, ya que creo que es principalmente una cuestión de perspectiva. Algunos problemas se atacan mejor con técnicas funcionales, otros con técnicas de programación orientada a objetos. Un buen programador siempre mira un problema difícil desde diferentes ángulos, antes de intentar una solución. O, como lo expresó Alan Kay: el punto de vista vale 80 puntos de coeficiente intelectual .

Entonces, mi respuesta a tu pregunta es: ¿De qué mundo real estás hablando? ¿Y cómo?

Si bien algunos objetos que creo están modelando objetos del mundo real, ¿no haría lo mismo el código pre-OOP?

Yo diría que no. OOP vincula la relación entre las cosas (propiedades / objetos) y lo que pueden hacer / se les puede hacer (métodos), mientras que la programación de procedimientos no hace esto (aparte de, en un pequeño grado, cuando se usa una escritura estricta). Un modelo no se trata solo de definir partes y procesos discretos, también se trata de definir cómo encajan entre sí, y OOP es particularmente bueno en esto.

He visto que se repite comúnmente que la programación orientada a objetos se basa en modelar el mundo real, ¿pero es así?

Si. El énfasis aquí se basa en . OOP no modela el mundo real (si lo hace, entonces por cierto) y no se supone que lo haga. Lo que hace OOP es permitirnos modelar problemas de programación de la forma en que modelamos el mundo real: como un sistema de entidades que se definen a través de nuestra abstracción de su comportamiento.

El código OO generalmente no modela el mundo real; al menos ese no es el objetivo, simplemente le permite pensar en su código de una manera más natural, más como la forma en que piensa sobre las cosas en el mundo real: Esto es lo que la cita intenta decir.

No modela nuestro mundo, pero sí modela la interpretación humana de nuestro mundo. Los humanos separan naturalmente las cosas como objetos. OO es efectivo porque permite a los humanos programar su forma de pensar.

OOP puede no ser un modelo perfecto del mundo real y de los objetos que contiene, pero es una metodología que ayuda a lidiar con la creciente complejidad del software de la vida real. También ayuda a escribir mejor el código, descomponiéndolo en fragmentos lógicamente relacionados.

Si bien los métodos orientados a procedimientos más antiguos ciertamente también brindarán resultados, OOP lo ayuda a llegar más rápido y con relativa facilidad, incluso cuando se trata de proyectos grandes y complejos.

La abstracción y la encapsulación ayudan a concentrarse en el núcleo del problema mientras ocultan toda la tubería que realmente hace que las cosas sucedan. Herencia y le permite establecer una relación significativa y lógica entre varios aspectos de su código. El polimorfismo promueve la reutilización del código y le permite manejar fácilmente las variaciones (la categoría de problemas " casi el mismo comportamiento que un objeto existente" que ocurre con tanta frecuencia) y extender el código al extender la semántica asociada a un objeto.

Siento que la OOP es más como una ayuda comprobada que le permite lidiar con todas las complejidades de un sistema de la vida real de manera efectiva. Entonces, si bien puede no ser un modelo muy completo del mundo real, está lo suficientemente cerca y te ayuda a hacer las cosas, lo que en mi humilde opinión es todo lo que importa al final.

He visto que se repite comúnmente que la programación orientada a objetos se basa en modelar el mundo real, ¿pero es así?

Me parece que eso no es cierto para nada fuera de la capa empresarial.

No. Como usted señala, muchas de las cosas "modeladas" en un lenguaje OOP son conceptos abstractos como colas de mensajes y controladores y pilas.

Incluso en su capa empresarial, todavía no está modelando "el mundo real". Suponga que tiene una clase de empleado. Los empleados también son personas, que también son mamíferos, que también son animales, que también son ... (bostezo) Los empleados tienen sus colores favoritos, y usan ciertas ropas y creen ciertas cosas. En resumen, hay una gran variedad de complejidad en el mundo real que ni siquiera intentamos capturar en la mayoría de los programas.

En el modelado, solo nos enfocamos en los aspectos del modelo que son significativos para la tarea en cuestión. Si estamos diseñando un sistema de entrada de tiempo, entonces probablemente queremos algún tipo de clase de Empleado, pero esa clase no necesita una propiedad para expresar el color favorito del empleado.

Por lo tanto, los modelos no deberían intentar (o pretender) representar completamente el "mundo real".

Si bien algunos objetos que creo están modelando objetos del mundo real, ¿no haría lo mismo el código pre-OOP? Dudo que OO haya sido la primera persona en incluir conceptos como Cliente en sus bases de código.

Estás en lo correcto. Si observa programas grandes que no son OOP, a menudo todavía están organizados en torno a estructuras de datos. Una estructura de datos y todas las funciones que manipulan se definen una cerca de la otra, por razones de claridad. (El proyecto de subversión es un buen ejemplo de esto. Las estructuras y funciones de datos tienen como prefijo los nombres de los módulos para que quede claro qué estructuras y funciones están destinadas a usarse entre sí).

No soy un experto en la historia de los lenguajes de programación, pero imagino que OOP surgió de la observación casual de que el código era más claro y fácil de entender cuando se organizó de esta manera, por lo que los diseñadores de idiomas comenzaron a diseñar idiomas donde ese tipo de organización era más estrictamente aplicado.

La mayor diferencia entre OOP y no OOP es que OOP une el código a los datos. Entonces, en lugar de llamar a un código como este:

verb(noun);

hacemos esto en su lugar:

noun->verb();

Aunque esto puede parecer una diferencia gramatical, la diferencia está realmente en la mentalidad. Les decimos a los objetos qué hacer, y generalmente no nos importa cuál es el estado interno o el funcionamiento del objeto. Al describir un objeto, solo necesitamos describir su interfaz pública para poder trabajar con él.

¿La programación orientada a objetos realmente modela el mundo real?

No completamente.

Bueno, en el mundo real, nos enfrentamos a problemas reales. Deseamos resolver este problema utilizando un paradigma que replica el sistema que deseamos construir y que se convierte en el modelo.

Por ejemplo, si el problema en cuestión era una aplicación de carrito de compras, tenemos diferentes entidades como

1. Producto que es un término abstracto que puede tener múltiples miembros como Libros, Gadgets, Autos que nuevamente pueden subdividirse.

2. Criterios fiscales como (Impuesto sobre las ventas) dependerían de la ubicación en la que se implemente el software, ya que está sujeto a cambios según las políticas gubernamentales.

3. El impuesto se considera en función de si el producto se importó junto con los criterios fiscales.

4. El usuario podría tener un carrito de compras que tenga una lista de productos, etc.

Como puede ver, hay problemas reales que estamos tratando de resolver, pero modularizados según el paradigma OOP para que esté lo más cerca posible del sistema real.

Creo que está leyendo demasiado en lo que pretende ser una declaración muy prosaica e histórica. Muchas de las ideas de programación OO, clases, polimorpismo, funciones virtuales, etc. se introdujeron en el lenguaje Simula, en la década de 1960 (http://en.wikipedia.org/wiki/Simula). Como su nombre indica, Simula fue diseñado para ser un lenguaje para escribir simulaciones. Históricamente, sí, las ideas OO se introdujeron en un esfuerzo por modelar el "mundo real". Si tienen éxito más que otros estilos es un tema de debate.

Si bien algunos objetos que creo están modelando objetos del mundo real, ¿no haría lo mismo el código pre-OOP?

La mayor diferencia entre el código OOP y el código pre-OOP es que el primero modela una situación del mundo real como un grupo de entidades distintas que interactúan entre sí, cada una con un "poder" limitado con respecto a lo que puede hacer, y también capaz de "reaccionar" a eventos externos con acciones propias. Este último modela todo como una gran porción de datos que no hace nada por sí mismo, mientras que el cómputo representa "cosas que suceden" y puede afectar a una o todas ellas.

Si modela mejor el mundo real o no, eso realmente depende de qué facetas del mundo estés modelando. Una simulación física, por ejemplo, en la que desea describir los efectos que, por ejemplo, tendría un fuego encendido en los objetos circundantes, estaría mejor representada por un enfoque "tradicional", ya que tanto la luz como el calor están bien. procesos definidos que afectan tanto el estado externo como interno de otros objetos, y no varían de acuerdo con el comportamiento de cada objeto en particular, solo se ven afectados por sus propiedades.

Por otro lado, si está modelando diferentes componentes que interactúan para producir el comportamiento deseado, tratarlos como agentes en lugar de cosas pasivas puede hacer que sea más fácil hacerlo correctamente sin perder nada. Si quiero encender mi televisor, solo presiono el botón, si el cable de alimentación está desconectado, TV.turnOnlo comprobaré por mí. Por lo tanto, no hay riesgo de girar un engranaje y olvidarse de encender otro que lo está tocando, ya que el engranaje mismo (si está programado correctamente) se encargará de las interacciones secundarias que surjan como consecuencia de la primaria.

Pero OO realmente trata sobre cómo modelar cosas, y ese método de modelado no me parece inspirado por el mundo real.

Creo que tiene más que ver con la forma en que percibimos el mundo que con cómo es realmente el mundo. Se podría argumentar que todo es solo un montón de átomos (o energía, u ondas, lo que sea), pero eso no nos ayuda a manejar la tarea de enfrentar los problemas que enfrentamos, comprender el entorno que nos rodea y predecir eventos futuros ( o describiendo los pasados). Por lo tanto, hacemos "modelos mentales" del mundo, y a menudo esos modelos mentales encuentran una mejor correspondencia con OO que los procesos de datos +, lo que posiblemente modela "mejor" cómo funciona realmente el mundo real.

También es interesante notar que la mayoría de la gente piensa en OOP como sinónimo de "OOP clásica", donde creamos taxonómicamente conjuntos y subconjuntos de cosas, y colocamos objetos sin ambigüedad en un conjunto muy específico. Eso es muy útil para crear nuevos tipos reutilizables , pero no es tan bueno cuando la entidad que estás modelando es bastante autónoma y, aunque inicia interacciones con otros objetos, rara vez, si alguna vez, es el objetivo de una interacción. O peor, cuando hay pocas (tal vez una sola) instancia de esa entidad, o las instancias varían enormemente en composición, comportamiento o ambas.

Sin embargo, también hay una "POO prototípica", donde se describe un objeto eligiendo uno similar y enumerando los aspectos en los que difieren. Sugeriría este ensayo para una explicación buena y no demasiado técnica del proceso de pensamiento (toda la publicación es demasiado grande, incluso para los estándares de Steve Yegge, por lo que estoy señalando la sección relevante: P). Nuevamente, esta es una buena combinación para nuestros modelos mentales cuando imaginamos instancias desconocidas en comparación con una conocida, pero no necesariamente para cómo "funciona" el mundo real ... (dos vacas son en realidad entidades completamente distintas, incluso si las percibimos como ser "similar" en muchos sentidos)

Creo que "sí" es la parte importante de esta pregunta. Creo que la programación orientada a objetos ciertamente puede modelar "objetos" del mundo real, pero esto es programación . No existe una metodología que no se pueda abusar, por lo que no creo que sea justo decir "OOP no modela el mundo real" solo porque puedes hacer cosas estúpidas con objetos. Eso no es más justo que decir que los Punteros no son seguros porque puedes hacer cosas estúpidas con los punteros.

El artículo de Wikipedia sobre el asunto lo resume bien:

Modelado y relaciones del mundo real
OOP se puede utilizar para asociar objetos y procesos del mundo real con sus homólogos digitales. Sin embargo, no todos están de acuerdo en que OOP facilita el mapeo directo del mundo real (ver la sección Crítica negativa) o que el mapeo del mundo real es incluso un objetivo digno; Bertrand Meyer argumenta en Construcción de software orientado a objetos [21] que un programa no es un modelo del mundo sino un modelo de alguna parte del mundo; "La realidad es un primo dos veces eliminado".

La cuestión es que, a menos que su programa sea una simulación universal, solo le interesan partes del mundo real, por lo tanto, "modelo". Para eso están los modelos, te dan la estructura y la funcionalidad que necesitas para mostrar.

En el mundo real tenemos cosas (objetos) y las cosas pueden realizar acciones (métodos). Podemos cuantificar aspectos de las cosas (Propiedades). OOP tiene todo el potencial para modelar cosas del mundo real cuando se usa de manera reduccionista; cada cosa compleja tiene subclases más pequeñas o más específicas y todas estas cosas tienen interacciones naturales a través de métodos.

OOP es un método de abstracción, por lo que lo práctico es si OOP realmente modela lógicamente objetos en el mundo real, es menos importante que no esté modelando todas las cosas posibles que todo podría hacer . Si necesita hacer todo lo posible, en realidad no está modelando .

Para pensar en la orientación a objetos en su contexto adecuado, avancemos un nivel de abstracción y hablemos de programación en general, ¿de acuerdo?

Independientemente de si tomas OO o enfoques funcionales, tu programa tiene que hacer algo, ¿no? El objetivo del programa es exhibir ciertos comportamientos dado un cierto conjunto de estímulos. Entonces, las razones por las que los programas existen son porque hacen algo. La palabra clave aquí es comportamiento .

Además de considerar qué comportamientos debe implementar un programa, su programa generalmente necesita exhibir ciertas cualidades. Por ejemplo, no es suficiente para un programa de monitor cardíaco tener los comportamientos que se requieren de él; por lo general, también debe funcionar lo suficientemente rápido como para operar en tiempo casi real. Otras "cualidades" que un programa puede necesitar exhibir son: seguridad, flexibilidad, modularidad, extensibilidad, legibilidad, etc. Llamamos a estos atributos de calidad de arquitectura . Por lo tanto, podemos decir que nuestro programa necesita cumplir con ciertos objetivos de comportamiento (funcionales) y exhibir ciertas cualidades (no funcionales).

Hasta ahora, nada de esto ha hablado de OO, ¿verdad? Hagámoslo ahora.

Una vez que un ingeniero comprende los requisitos (comportamiento, AQA, restricciones, etc.), surge la pregunta: ¿cómo debo organizar mi código para que haga todas las cosas que tiene que hacer mientras exhibe las cualidades necesarias para ser un programa útil? La programación orientada a objetos es una estrategia para organizar la funcionalidad de su programa en módulos cohesivos de objetos que cooperan. La programación funcional es solo otra estrategia para organizar la funcionalidad de su programa, y ​​lo hace de una manera diferente. Ambas estrategias tienen sus fortalezas y debilidades.

Hemos sido testigos de un resurgimiento reciente en conceptos funcionales porque tiene fortalezas que son muy convincentes para un procesamiento ampliamente distribuido, entre otras razones.

Pero volviendo a OO, puede ver ahora que no necesariamente modela el "mundo real"; lo que hace es organizar el comportamiento de su programa para que su programa pueda exhibir las cualidades necesarias para cumplir con cualquier número de objetivos comerciales. Técnicas como TDD, DDD y BDD son las formas en que descubrimos la mejor manera de organizar nuestros objetos. Libros como Principios, Patrones y Prácticas , Crecimiento de software orientado a objetos guiado por pruebas , Especificación por ejemplo y Diseño impulsado por dominios exponen la teoría y la práctica de la orientación a objetos con un enfoque en el diseño basado en el comportamiento.

Cuando lee sobre cosas como "observadores, gerentes, fábricas, etc.", está aplicando patrones de OO que ayudan a que su programa exhiba ciertas cualidades que pueden ser necesarias para que sea útil. Son "recetas probadas" que "tienden a funcionar", dado que sus necesidades coinciden con el problema que resuelve el patrón.

Espero que eso te ayude a entender de qué se trata OO sin parecer demasiado sesgado entre OO y los paradigmas funcionales.

OOP crea un modelo agradable desde el punto de vista de la programación, no refleja el mundo real.

Sin embargo, existen aproximaciones mucho mejores del mundo real, que se conocen con el término lenguaje específico de dominio ( DSL ). Por ejemplo, Boo le brinda la capacidad de escribir código legible por humanos en un inglés casi sencillo (muestra del artículo ).

apply_discount_of 5.percent:
         when order.Total > 1000 and customer.IsPreferred
         when order.Total > 10000

suggest_registered_to_preferred:
         when order.Total  > 100 and not customer.IsPreferred

Otro ejemplo serían los marcos automatizados de pruebas de aceptación de usuarios basados ​​en el lenguaje Gherkin .

Feature: Some terse yet descriptive text of what is desired
    In order to realize a named business value
    As an explicit system actor
    I want to gain some beneficial outcome which furthers the goal

Scenario: Some determinable business situation
    Given some precondition
        And some other precondition
    When some action by the actor
        And some other action
        And yet another action
    Then some testable outcome is achieved
        And something else we can check happens too

Depende de usted, finalmente. Pero OOP es una manera precisa de hacerlo que otras metodologías como la programación estructurada u orientada a procedimientos. El tacto real podría resolver sus problemas, pero seguir OOP puede facilitarle la vida.