Confundido.¿Es la OO inherentemente imperativa o es multiparadigma?

Question

Al leer las respuestas y preguntas de stackoverflow, tengo la impresión de que OO está compartimentado para ser inherentemente imperativo.

¿Pero no es OO solo una forma de compartimentar código y datos en objetos del mundo real?

Si es así, ¿por qué renunciaría a otro paradigma de nivel inferior para trabajar en una plataforma de este tipo?

IOW, un sistema de tipos genéricos basado en objetos que es inmutable por defecto sería la forma en que funcionaría un primer lenguaje funcional, un sistema de tipos genéricos basado en objetos que es mutable por defecto sería el mundo de los lenguajes imperativos.

¿O me estoy perdiendo algo por completo?

Answer 1

No . OO e imperativa son dos conceptos ortogonales.

Por ejemplo:

• El Common Lisp Object System es un ejemplo de Lisp OO y tal vez el sistema objeto más complejo alrededor.
• OCaml es un lenguaje funcional con un sistema de objeto y un sistema de módulo de soporte orientado a objetos organización
• Scala es un lenguaje funcional con un sistema OO muy flexible
• Haskell le permite escribir código orientado a objetos utilizando el polimorfismo kinded de mayor

Hay un montón de diferentes maneras de ser orientado a objetos.

Answer 2

La mayoría de los lenguajes orientados a objetos son imprescindibles, pero puede usarlos en un estilo algo funcional. Algunos lenguajes funcionales se sientan encima de un marco orientado a objetos (F # en .NET es el ejemplo más obvio) la negociación fuera cierta "pureza" con el fin de conseguir un marco masivo para utilizar en su caso.

Creo que hay un mucho de espacio para las lenguas "principalmente OO" que hacer más para ayudar a programar de forma funcional - un mejor soporte para la inmutabilidad siendo la característica más obvia, posiblemente seguida de una mejor inferencia de tipos . (Por lo menos cuando se habla de C #, que es probablemente el ejemplo más significativo de un lenguaje tradicional tratando de conseguir un pie en la puerta funcional.)

Answer 3

Sí. orientada a objetos es un estilo de programación que permite al programador para expresar un programa como un conjunto de objetos con estado que actúan e interactúan (por lo general, mediante paso de mensajes de tipos dinámicos, lenguas y método de invocación en lenguajes de tipo estático), y hacerlo en una secuencia particular.

Estado, la acción y la secuencia son conceptos de la programación de procedimiento y no están presentes en la programación funcional nonmonadic (mónadas se utilizan para implementar estado, la acción y la secuencia en los lenguajes funcionales puros Haskell, que de otro modo no tendría estos conceptos).

Answer 4

Para mirarlo desde una perspectiva diferente, la mayoría de la gente le gusta pensar imperativamente (en lugar de en recurrencias o RPN). De esto se desprende que la mayoría de los idiomas estarán imprescindible.

Por supuesto, muchos problemas son mucho más fáciles de expresar (o resolver) con un enfoque no imperativo (por ejemplo, las interfaces de usuario) pero la mayoría de la gente realmente no se sienten cómodos con este enfoque. Algunos no desea abandonar el camino trillado, mientras que otros realmente tienen problemas para hacer el cambio mental necesaria para abordar los problemas de este lado (pensando en las llamadas a métodos y recursividad en lugar de variables y bucles).

Answer 5

Todavía firmemente que la orientación a objetos es un concepto inherentemente imprescindible. Sin embargo, como reciente pregunta me hizo pensar un poco más sobre los paradigmas de programación en general, junté una respuesta más amplia, que es un poco fuera de tema, pero por cierto también responde a su pregunta:

Los 2 principales paradigmas de programación son los paradigma declarativo , donde el programador escribe relaciones abstractas (con lo que indica el compilador lo que quiere), y el imperativo paradigma , donde el programador escribe algoritmos (contando por lo tanto el equipo ¿Cómo para conseguir lo que quiere).

Los paradigmas son un lenguaje-agnóstico priori - es más bien una manera de cómo se piensa y la estructura de su programa. Sin embargo, existen diferencias en lo fácil una lengua hace que utilizar un paradigma:. Semántica del lenguaje y el plomo sintaxis para una forma idiomática de la escritura de código

Un ejemplo de un lenguaje declarativo sería Prolog, un ejemplo de un lenguaje imperativo sería Fortran (y Propiedades programador puede escribir programas FORTRAN en cualquier idioma ).

Como ejemplo de código que es imperativa y declarativa, al mismo tiempo, tenga en cuenta esta implementación del Fibonnaci-secuencia en Perl6:

my @fibonacci-sequence := 0, 1, * + * ... *;

Esto es claramente una descripción declarativa de la secuencia. Sin embargo, como * y ... son válidos los operadores Perl6 - el que sea estrellas se puede utilizar para crear expresiones lambda, la secuencia de operador crear listas perezosos -. También es imprescindible una declaración invocando el código de ejecución-intrínseca

Vamos a considerar algunos otros paradigmas de programación, en la programación funcional y orientado a objetos en particular.

La paradigma funcional es inherentemente declarativa, ya que los modelos de cálculo como una relación entre las series.

La paradigma orientado a objetos es inherentemente imperativo, ya que los modelos de cálculo como la comunicación entre objetos con estado, llamado paso de mensajes.

Algunos idiomas son puros, es decir, todos los cálculos se ajusta al paradigma. Por ejemplo, Haskell es un lenguaje puramente funcional, y Smalltalk es un lenguaje puramente orientado a objetos.

Sin embargo, esto no quiere decir que los lenguajes funcionales que resp. lenguajes orientados a objetos impiden resp imprescindible. programación declarativa. En la práctica, a menudo se utiliza funciones imperativamente - se pone en un valor de entrada para salir un valor de salida. Lo contrario es cierto para la programación orientada a objetos:. El conjunto de mensajes de un objeto acepta declara su interfaz

Answer 6

Algunas personas no están de acuerdo en OO siendo un concepto imprescindible, así que aquí está mi razonamiento.

Esenciales orientación a objetos:

1. objetos de mantenimiento de estado (es decir, referencias a otros objetos)
2. objetos reciben (y proceso) mensajes
3. procesar un mensaje puede resultar en
   • mensajes beeing enviados al objeto en sí mismo u otros objetos
   • un cambio en el estado del objeto

Esto significa oo-programación requiere el estado mutable contenida en el objeto (!) . Si simula cambio de estado mediante la creación de una serie de objetos, que está rompiendo estas invariantes, así de simple.

flamebait:. Si no está de acuerdo con esta definición de la orientación a objetos, lo toman con Alan Kay

Answer 7

Muchos conceptos diferentes contribuyen al concepto de Programación Orientada a Objetos. Wikipedia enumera la mayoría de ellos.

Caracterizaría la esencia de la programación orientada a objetos por el uso de Objetos con comportamientos.

Wikipedia caracteriza Objetos por las siguientes tres propiedades:

1. Identidad:propiedad de un objeto que lo distingue de otros objetos
2. Estado:describe los datos almacenados en el objeto
3. Comportamiento:Describe los métodos en la interfaz del objeto mediante los cuales se puede utilizar el objeto.

Muchos lenguajes orientados a objetos tienen un concepto de clases, pero en realidad también existen Lenguajes basados ​​en prototipos como JavaScript.

Los lenguajes funcionales también pueden usar clases (p. ej.Clases tipográficas en Haskell).Pero el hecho de que tengan clases no significa que estén orientados a objetos o que permitan la programación orientada a objetos.Para seguir con el ejemplo de Haskell:¡Ni siquiera tienes Objetos!¡No existe el concepto de "identidad"!¡Todo lo que puedes hacer es componer funciones puras!

¡El hecho de que alguien esté usando un término llamado "clases" no significa que esté haciendo programación orientada a objetos!

La programación orientada a objetos se trata de objetos con estado y comportamiento.Aunque el comportamiento de los objetos no tiene que modificar ese objeto porque en su lugar se pueden crear nuevos objetos, perderías la necesidad de los Objetos por completo.Ya no necesitarías Identidades, porque no importa si los cambios en un objeto se reflejan en otras referencias al mismo objeto porque ya no habría ningún cambio.Todo lo que necesita son Valores (sin identidad) y Módulos y/o Clases para ocultar y encapsular datos.

Entonces Sí, la programación imperativa es inherente a la programación orientada a objetos.