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

50

Lo he visto repetido con frecuencia, la programación orientada a objetos se basa en modelar el mundo real, ¿no es así?

Me parece que 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 de negocios, tengo clases como observadores, gerentes, fábricas, etc. que no son objetos del mundo real. Intento diseñar mis clases para aprovechar las ventajas de la encapsulación, pero ¿está el mundo real encapsulado?

Mientras que 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. 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?

    
pregunta Winston Ewert 01.11.2018 - 18:02

20 respuestas

51

No, en absoluto.

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

    
respondido por el Darknight 02.03.2012 - 16:44
33

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

Modelan partes seleccionadas , aquellas que son relevantes para la aplicación en cuestión.

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

    
respondido por el Oded 02.03.2012 - 21:26
30

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 te 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 después del mundo real?

NO

Haber 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. Cuánta simplificación es suficiente para expresar la necesidad comercial actual, y lo que se debe omitir, es un buen equilibrio entre el uso exitoso de la técnica frente a perderse con ella o no usarla en absoluto.

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

    
respondido por el Dipan Mehta 02.03.2012 - 22:24
17

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

Lo que se debe enseñar es que las clases modelan objetos abstractos, tal como lo hace tu cerebro. Tiene un concepto abstracto de "automóvil" en su cabeza que no se corresponde con ningún automóvil físico en particular, es reutilizable, las implementaciones específicas del automóvil pueden heredarse de él. Tu cerebro incluso meta-modela conceptos para ti. 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 tu cabeza, estarían mucho mejor preparados para construir software real.

    
respondido por el menacingly 02.03.2012 - 15:50
7
  

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

     

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

Los procesos son extremadamente comunes en el mundo real y en la programación. Se han desarrollado mecanismos elaborados a lo largo de los años para manejar transacciones, flujo de trabajo, orquestación, hilos, protocolos y otros conceptos inherentemente "de procedimiento". Esos mecanismos engendran complejidad al tratar de compensar la deficiencia inherente invariable en el tiempo en la programación OO. En su lugar, el problema se debe abordar en la raíz permitiendo construcciones específicas del proceso, como 'antes / después', 'causa / efecto' y, quizás, 'estado del sistema' sea una parte central del lenguaje ...

fuente de la cita: Victoria Livschitz, El siguiente movimiento en la programación

    
respondido por el gnat 02.03.2012 - 16:32
5

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

  

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

No confunda el desarrollo orientado a objetos con los patrones de diseño. El análisis y diseño de OO es un medio para abordar 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 según su contraparte del mundo real. Por ejemplo, si tenemos una guitarra, entonces una clase de guitarra resume los comportamientos y las propiedades de una guitarra del mundo real. Podemos abstraer aún más la guitarra como, digamos, un IInventoryItem para aprovechar el potencial de reutilización del código a través del polimorfismo y la herencia.

Por otra parte, 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 para crear con éxito un código de mantenimiento para tal propósito. 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 modelar el mundo real" tiene mucho sentido.

    
respondido por el P.Brian.Mackey 02.03.2012 - 17:00
4
  

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

Yo diría que no. La POO 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 grado pequeño, cuando se usa la tipificación 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.

    
respondido por el wheresrhys 02.03.2012 - 17:50
4

Depende de qué mundo real estés hablando.

Jorge Luis Borges escribió una historia "Tlön, Uqbar, Orbis Tertius", donde un pueblo habitante parece percibir su mundo real de manera muy diferente:

[...] la gente del imaginario Tlön [...] tiene 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 monosilábicos o prefijos que tienen la fuerza de los adverbios". Borges enumera un equivalente en 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 puesta en marcha de la luna". [...] En otro lenguaje de Tlön, "la unidad básica no es el verbo, sino el adjetivo monosilábico", que, en combinaciones de dos o más, forman un sustantivo: "luna" se convierte en "luz aérea redonda" Oscuro "o" pálido-naranja-del-cielo.

(copiado del wikipedia artice sobre el libro)

Para mí, el punto no es tanto que el mundo pueda percibirse de manera diferente a lo que lo hacemos nosotros, lo que es un poco cliché, sino que la percepción de la estructura de la realidad en sí misma depende del idioma que hablemos, ya sea natural o lenguaje 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 preferir los objetos orientados a los lenguajes funcionales. Me gustan los dos estilos, ya que creo que es principalmente una cuestión de perspectiva. Algunos problemas son mejor atacados con funcional, 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 dijo Alan Kay: El punto de vista vale 80 puntos de inteligencia .

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

    
respondido por el pillmuncher 03.03.2012 - 22:45
3
  

Lo he visto repetido comúnmente la programación orientada a objetos es   basado en modelar el mundo real, pero ¿lo es?

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

    
respondido por el back2dos 02.03.2012 - 17:45
3

El código OO no suele modelar el mundo real, al menos ese no es el objetivo, simplemente te permite pensar en tu código de una manera más natural, más como la forma en que piensas sobre las cosas en la realidad. mundo - esto es lo que la cita está tratando de decir.

    
respondido por el Bill K 02.03.2012 - 20:00
3

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

    
respondido por el Dokkat 03.03.2012 - 21:01
2

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, dividiéndolo en partes lógicamente relacionadas.

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

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

Siento que la POO es más como una ayuda probada que te permite lidiar con todas las complejidades de un sistema de la vida real de una manera efectiva. Entonces, aunque puede que no sea 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.

    
respondido por el Bhargav Bhat 02.03.2012 - 16:01
2
  

Lo he visto repetido con frecuencia, la programación orientada a objetos se basa en modelar el mundo real, ¿pero no?

     

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

No. Como 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". Supongamos 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 colores favoritos, visten cierta ropa y creen en 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 centramos en los aspectos del modelo que son significativos para la tarea en cuestión. Si estamos diseñando un sistema de entrada de tiempo, es probable que queramos 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 deben intentar (o pretender) representar completamente el "Mundo Real".

  

Mientras que 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 subversion project es un buen ejemplo de esto. Las estructuras y funciones de los datos tienen el prefijo de los nombres de los módulos, por lo que que está claro qué estructuras y funciones están diseñadas para usarse unas con otras.)

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

La mayor diferencia entre OOP y no OOP es que OOP vincula el código a los datos. Así que 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. Le 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.

    
respondido por el Mark E. Haase 02.03.2012 - 17:19
2
  

¿La programación orientada a objetos modela realmente 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 una aplicación de Carro de la compra era el problema en cuestión, tenemos diferentes entidades como

  1. Producto , que es un término abstracto que puede tener varios miembros como Libros, Gadgets, Coches que pueden subdividirse nuevamente.

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

  3. Tax 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 tiene una lista de productos, etc.

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

    
respondido por el Karthik Sreenivasan 02.03.2012 - 17:34
2

Creo que estás leyendo demasiado sobre 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. Así que 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 una cuestión de debate.

    
respondido por el Charles E. Grant 02.03.2012 - 18:01
2
  

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 " Reaccionando "ante eventos externos con acciones propias. Este último modela todo como una gran cantidad de datos que no hace nada por sí solo, mientras que el cálculo representa "cosas que suceden" y puede afectar a cualquiera o a todos ellos.

Tanto si modela mejor el mundo real como si no, eso realmente depende de qué facetas del mundo estás modelando. Una simulación de física, por ejemplo, donde desea describir los efectos que, por ejemplo, un fuego que se está encendiendo tendría 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 el estado externo e interno de otros objetos, y no varían según 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, simplemente presiono el botón, si el cable de alimentación está desenchufado, TV.turnOn lo comprobará por mí. Por lo tanto, no hay riesgo de girar una rueda dentada y olvidarse de la otra que la está tocando, ya que la propia rueda dentada (si está programada correctamente) se ocupará de las interacciones secundarias que surjan como consecuencia de la principal.

  

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 nosotros percibimos el mundo que cómo es realmente el mundo. Se podría argumentar que todo es solo un grupo de átomos (o energía, u ondas, lo que sea), pero eso no nos ayuda a manejar la tarea de lidiar con los problemas que enfrentamos, con entender el entorno que nos rodea y predecir eventos futuros ( o describiendo los pasados). Así que creamos "modelos mentales" del mundo y, a menudo, esos modelos mentales encuentran una mejor correspondencia con OO que los datos + procesa uno, lo que podría decirse que "mejor" es cómo funciona el mundo real.

También es interesante observar que la mayoría de la gente piensa que la POO es sinónimo de "POO clásica", donde creamos taxonómicamente conjuntos y subconjuntos de cosas, y colocamos los objetos de forma inequívoca en un conjunto muy específico. Eso es muy útil para crear nuevos tipos reutilizables , pero no tanto cuando la entidad que está modelando es bastante autónoma, y aunque inicia interacciones con otros objetos, rara vez, si es que alguna, lo es. objetivo de una interacción. O peor, cuando hay pocas (quizás solo una) instancia de esa entidad, o las instancias varían enormemente en la composición, el comportamiento o ambos.

Sin embargo, también hay un "OOP prototípico", en el que se describe un objeto seleccionando uno similar y enumerando los aspectos en los que difieren. Sugeriría este ensayo para un buen y no demasiado Explicación técnica del proceso de pensamiento (todo el post es demasiado grande, incluso para los estándares de Steve Yegge, así que estoy señalando la sección correspondiente: 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 por la forma en que "funciona" el mundo real ... (dos vacas son en realidad entidades completamente distantes, incluso si las percibimos como ser "similar" en muchos sentidos)

    
respondido por el mgibsonbr 03.03.2012 - 00:51
1

Creo que "Does" es la parte importante de esta pregunta. Creo que la programación orientada a objetos sin duda puede modelar "objetos" del mundo real, pero esto es programación . Existe una metodología no que no se puede 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. No es más justo decir que los punteros no son seguros porque puedes hacer cosas estúpidas con punteros.

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

  

Modelos y relaciones en el mundo real
  La POO se puede utilizar para asociar objetos y procesos del mundo real con sus equivalentes digitales. Sin embargo, no todos están de acuerdo en que la OOP facilita el mapeo directo del mundo real (consulte la sección Crítica negativa) o que el mapeo del mundo real es incluso una meta valiosa; Bertrand Meyer sostiene en la Construcción de software orientada 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 eliminado dos veces".

Lo importante es que, a menos que su programa sea una simulación de universo, solo le importa las partes del mundo real, de ahí el "modelo". Para eso son los modelos, le brindan la estructura y la funcionalidad que necesita para mostrar.

En el mundo real tenemos cosas (Objetos) y las cosas pueden realizar acciones (métodos). Podemos cuantificar aspectos de las cosas (Propiedades). La 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, así que lo práctico es si OOP realmente lógicamente modela objetos en el mundo real, es menos importante que no esté modelando cada cosa posible. podría hacer . Si necesitas hacer todas las cosas posibles, no estás realmente modelando.

    
respondido por el Ben Brocka 02.03.2012 - 18:41
1

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

Independientemente de si toma OO o enfoques funcionales, su programa tiene que do algo, ¿no es así? El objetivo principal del programa es mostrar ciertos comportamientos dado un cierto conjunto de estímulos. Así que las razones por las que existen los programas es porque do algo. La palabra clave aquí es comportamiento .

Además de considerar qué comportamientos debe implementar un programa, su programa generalmente debe mostrar ciertas cualidades. Por ejemplo, no es suficiente que un programa de monitorización del corazón tenga los comportamientos requeridos, por lo general, también necesita un desempeño lo suficientemente rápido 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 la arquitectura . Por lo tanto, podemos decir que nuestro programa debe cumplir con ciertos objetivos de comportamiento (funcionales), así como exhibir ciertas cualidades (no funcionales).

Hasta ahora, nada de esto ha hablado de OO, ¿verdad? Vamos a hacer eso 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 todo lo que necesita hacer y al mismo tiempo exhiba las cualidades necesarias para ser útil? ¿programa? La programación orientada a objetos es una estrategia para organizar la funcionalidad de su programa en módulos cohesivos de objetos cooperativos. 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 presenciado un resurgimiento reciente en los conceptos funcionales porque tiene fortalezas que son muy convincentes para el procesamiento enormemente 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 , Software orientado a objetos en crecimiento guiado por pruebas , Especificación mediante ejemplo y Diseño impulsado por dominio presenta 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 lees sobre cosas como "observadores, gerentes, fábricas, etc.", estás aplicando patrones OO que ayudan a tu programa a exhibir 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 esto te ayude a entender de qué se trata OO sin parecer demasiado sesgado entre OO y los paradigmas funcionales.

    
respondido por el John Ruiz 02.03.2012 - 22:29
1

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 lenguajes específicos del dominio ( DSL ). Por ejemplo, Boo le brinda la capacidad de escribir código legible para el ser humano en un inglés casi sencillo (muestra de articulo ).

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 de prueba de aceptación de usuarios automatizados 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
    
respondido por el oleksii 04.03.2012 - 00:11
0

Depende de ti, finalmente. Pero la OOP es una forma precisa de hacerlo que otras metodologías como la programación estructurada o orientada a procedimientos. El tacto del procedimiento posiblemente podría resolver sus problemas, pero seguir la OOP puede hacer su vida más fácil.

    
respondido por el Vishal 02.03.2012 - 17:50

Lea otras preguntas en las etiquetas