¿Es OOP el modelo de programación dominante en el mundo real?

20

¿Los objetos nunca? Bueno, casi nunca

En la sección PUNTO DE VISTA de Comunicaciones de The ACM, encontré un artículo interesante titulado "¿ Objetos nunca? Bueno, casi nunca ". Es una perspectiva radicalmente diferente a la de los objetos primero u objetos tardíos. Sugiere "objetos-nunca" o tal vez "objetos-escuela de posgrado".

El autor habló sobre OOP e hizo una pregunta sobre cómo se usa OOP en entornos de programación del mundo real. Él piensa que OOP no es el modelo de programación dominante. Por ejemplo, afirma, el 70% de las programaciones se realizan para sistemas embebidos donde la POO no es realmente adecuada.

Cuando algunos profesores en las universidades quieren hablar sobre los beneficios de la OOP, hablan sobre la reutilización de códigos. Como otro ejemplo, nuevamente, afirma, este no es el caso real en el mundo real. La reutilización de códigos es más difícil de lo que se afirma en las universidades:

Afirmo que el uso de OOP no es tan frecuente como la mayoría de la gente cree, que no es tan exitoso como afirman sus proponentes y, por lo tanto, que su lugar central en el plan de estudios de CS no está justificado.

¿Es interesante para mí saber cómo piensan las personas en el desbordamiento de pila sobre esto? ¿Es OOP el modelo de programación dominante desde el punto de vista de los programadores?

Si debo elegir / aprender / usar solo un enfoque, ¿es POO o no? ¿por qué?

Ehsan
fuente
26
¿"70% de las programaciones se realizan para sistemas integrados"? ¿Es por proyecto, por desarrollador o por LOC? Tengo la sensación de que el 70% de "todos los programas" se realiza en Excel. Incluso los no programadores programan hojas de cálculo.
LennyProgrammers
1
@ Lenny222: Si quiere adivinar, es el 70% de las copias distribuidas de los programas que se encuentran en software embebido, o algo así. Ahora, algunas cosas incrustadas se realizan en C ++ y, a menudo, una versión cortada que deja C y objetos, por lo que parece poco sincero argumentar que incrustado nunca está orientado a objetos.
David Thornley
99
Creo que el modelo de programación dominante ha sido y será la gran bola de barro.
whatsisname
Ese artículo hace una extraña distinción entre "clases" y "subsistemas" que ni siquiera entiendo remotamente. Habla sobre cómo DiskBrake extends Brakesignifica que la POO no es buena para un automóvil, porque en "el mundo real" esta comunicación se implementa "por medio de señales de red y protocolos de bus", ¿cómo DiskBrake implements BrakeInterface? Tal vez sea mi propia experiencia de 43 años, pero los ejemplos para mí no respaldan completamente la afirmación del autor.
OJFord
2
El enlace ahora está detrás de un muro de pago. De todos modos, OOP está poco definido y sobrevalorado en su mayor parte. Pero digamos que "la mayoría" de los nuevos programas que existen están probablemente escritos de alguna manera inspirada en Java con esquemas y captadores, y clases llamadas SessionManager
Charles Salvia

Respuestas:

19

En la sección PUNTO DE VISTA de Comunicaciones de The ACM

Si está interesado en la programación práctica , los procedimientos de ACM y similares son la última fuente que desea leer. Estas son a menudo publicaciones [pseudo] científicas sin aplicación en el mundo real. Estas son opiniones a menudo poco ortodoxas hechas para publicidad, para que el escritor se diferencie de la multitud y promueva a su propia persona.

Afirmo que el uso de OOP no es tan frecuente como la mayoría de la gente cree, que no es tan exitoso como afirman sus proponentes y, por lo tanto, que su lugar central en el plan de estudios de CS no está justificado.

Tiendo a estar en desacuerdo con tu punto. OOP está muy extendido y funciona bien. Por el número, los proyectos basados ​​en OOP probablemente han superado los desarrollos realizados con otras estrategias (hablemos de los tiempos modernos, 15-20 años).

Sin embargo, la POO no es una bala de plata. Funciona para algunos desarrollos, no funciona para otros. Como cualquier otro enfoque.

Pero una cosa que debo mencionar es que un plan de estudios debe comunicar el conocimiento de diferentes enfoques. Si está basado en OOP, está mal. Si está basado en FP, está mal. Debería cubrirlos a todos o no tocar este tema por completo.

PD ¿Por qué preocuparse por lo que es dominante y lo que no? Simplemente tome lo que sea adecuado para el proyecto en cuestión y deje los números a los "investigadores".


fuente
3
Son trabajos de investigación en los campos de la informática que aún no se han generalizado. La academia tarda muchos años en filtrarse al mundo real, aunque lo hace regularmente.
Orbling
44
@DeveloperArt: ¡Tenga en cuenta que el autor del artículo tiene 43 años de experiencia en desarrollo de software!
Ehsan
66
Alan Kay agrega un comentario, en cacm.acm.org/magazines/2010/9/… - 'Por el contrario, nunca he considerado que la mayoría de los sistemas que se autodenominan "orientados a objetos" estén cerca de mi significado cuando originalmente acuñé el termino.' - ¿Qué se relaciona tangencialmente con mi publicación - "OO? ¿De quién OO?"
Frank Shearar
99
@Developer Art: Lo que me molesta (un poco) de tu publicación es la parte de "investigadores". Esos malditos académicos. ¿Qué hicieron ellos por nosotros? Oh. Cálculo lambda, cierres, objetos, programación funcional, ... Pero aparte de eso, ¿qué han hecho los académicos por nosotros?
Frank Shearar
44
-1 ¿Los investigadores en informática necesitan citas de miedo? ¿La ACM publica pseudociencia? ¿Seriamente?
jprete
17

Si OOP es el único paradigma que conoce, tal vez debería aprender más. Pero realmente, ¿qué significa realmente la POO? ¿Significa Java o C ++? ¿Significa Smalltalk? ¿Significa ranuras y cierres de valores configurables? (Hola, Scheme!) ¿Significa enviar mensajes? (Hola, Erlang!)

En resumen, parece una pregunta poco interesante. "¿OO es útil ?" Es una mejor pregunta. Y, bueno, eso parece. (Ciertamente es para mí).

Frank Shearar
fuente
66
+1 Sospecho que en la práctica, OOP ha dejado de significar otra cosa que "una buena forma de escribir código que usa cosas llamadas objetos".
Larry Coleman
El artículo mencionado no cree que el uso de un lenguaje OO sea una garantía de uso oo y cuestiona si debería haber paradigmas ya que no existen en otras disciplinas de ingeniería.
JeffO
Quizás el autor debería leer a William Cook y Matthias Felleisen, quienes pasan mucho tiempo hablando de lo que es y no es lo mismo en la programación.
Frank Shearar
9

¿Dónde están todos los desarrolladores haciendo ese "70% de las programaciones"? De todos los desarrolladores que conozco, menos del 1% están trabajando en sistemas embebidos.

Entonces, tenemos 3 opciones:

  1. Soy único y todos tus amigos realmente hacen programación integrada
  2. Hay ejércitos de desarrolladores encerrados en un sótano que hacen el 70%
  3. esta estadística está hecha y el artículo es una mierda

a menos que vea alguna evidencia de que las opciones 1 o 2 son realmente verdaderas, voy con la opción 3.

(Por cierto, no considero la programación integrada de desarrollo móvil moderno, y el desarrollo móvil a menudo es OO, después de todo Apple te obliga a usar * Objective * C para desarrollar para el iPhone)

Nir
fuente
FWIW, me tomé unos segundos y se me ocurrieron media docena de posibles medidas para el "70% de las programaciones". El autor bien pudo haber usado un séptimo. (Además, los programadores integrados están ahí fuera, simplemente tienden a no pasar el rato en los mismos lugares y, a menudo, se consideran ingenieros eléctricos o algo así en lugar de programadores)
David Thornley,
1
@David Thornley: mentir con las estadísticas sigue mintiendo, el autor afirma claramente que la gran mayoría de la programación en el mundo de hoy es para sistemas integrados, y digo que esto es un toro total # @ $ t, estoy seguro de que puedo inventar un medida que muestra que la mayoría de la programación en el mundo se realiza en la sala en la que estoy ahora (que comparto con solo otro desarrollador), pero cualquier conclusión que construya sobre esta observación será tan inútil como la medida inventada .
Nir
1
Soy un chico incrustado. He visto varios informes de que aproximadamente el 99% de los procesadores producidos / enviados son para sistemas embebidos (si es realmente necesario, puedo volver y citar los informes). Dicho esto, estoy seguro de que cerca del 70% de toda la programación se realiza para sistemas integrados. Creo que algo así como el 50% de todos los procesadores enviados son de 4 bits y 8 bits, pero estos probablemente representan el 0.1% (o menos) de toda la programación. Como dijo David, hay muchas maneras de llegar al "70% de las programaciones". No me sorprendería si el número fuera del 20-25%.
Radian
+1 para "mentir con estadísticas sigue mintiendo"; tan cierto, tan cierto ...
Donal Fellows
8

No tengo hechos para seguirlo, pero OOP no es el modelo de programación dominante. Imagínense todas esas aplicaciones internas desarrolladas por alguien que tomó un curso básico visual o realizó alguna programación macro en Excel.

Muchas aplicaciones solo están haciendo una programación imperativa donde toda la lógica se acumula en una sola clase o vista. Esta es probablemente la gran mayoría de las aplicaciones simples internas que se ejecutan en todas las empresas.

No hay nada de malo en eso, hay varias formas de resolver el mismo problema. Algunos más adecuados que otros.

Además, como señaló, OOP no es útil para todos los escenarios. También hay otros modelos.

Morten
fuente
Por otra parte, podría haber la pregunta de qué se requiere para ser descrito como el modelo dominante. ¿Es "la cantidad de aplicaciones desarrolladas con el modelo X" o es "la cantidad de código desarrollado con el modelo X"? De cualquier manera, sigo pensando que OOP no será el modelo dominante.
Morten
1
+1 Para presentar el punto de que, si bien OOP puede estar casi en todas partes con profesionales capacitados, la industria en todo el mundo no refleja esto y hay un montón de código imperativo directo.
Orbling
5

Si OOP es o no el modelo de programación dominante es irrelevante, simplemente ponga diferentes modelos para diferentes casos.

No hay bala de plata.

Lo que Moti Ben Ari está discutiendo es una afirmación académica, que ya no tiene sentido. Sin embargo, él mismo afirma que nunca encontró que OOP "tuviera sentido", claramente lo hace para miles de desarrolladores e ingenieros de software y se ha utilizado en muchos sistemas ...

Pero, en realidad, el punto de mi respuesta es este: ¿de qué sirve afirmar que un modelo u otro es dominante o no, entonces es una buena razón para usarlo ciegamente? Por supuesto que no lo es.

ocodo
fuente
Si muchas personas afirman usar un modelo y no lo hacen, eso es un problema. La pregunta es tan frecuente como parece y no se trata de ser dominante / mejor.
JeffO
4

Esta es realmente una pregunta difícil de responder de manera confiable. La razón más importante es la gente como yo, que trabaja en aplicaciones internas personalizadas, donde el código nunca sale de nuestro edificio. ¿Usamos OO aquí? No estoy diciendo. ¿Cuántos otros programadores tienen trabajos similares? Ellos tampoco lo dicen. Tenemos sitios de trabajo, pero no todos los trabajos se publican, y no todos los anuncios son para trabajos reales en lugar de reclutadores que intentan recopilar listas de nombres.

Incluso si dije que usamos OO donde trabajo, ¿eso significa la definición tradicional del artículo vinculado: Objetos, Clases, Herencia? ¿O significa que uso objetos principalmente como un medio para organizar el código? ¿O significa que realmente solo programo interfaces y apenas uso la herencia? Todavía no lo digo, pero ¿cuál de estos realmente cuenta como OO?

Ni siquiera tiene sentido preguntar si OO es útil hasta que las preguntas anteriores hayan sido respondidas, y mucho menos dominantes.

Larry Coleman
fuente
2

Por supuesto que sí, porque es la última palabra de moda a la que se ha aferrado la gerencia. También ofrece una mejor encapsulación y abstracción que la programación imperativa, por lo que creo que el salto de oop a lo que viene a continuación podría llevar incluso más tiempo que el imperativo de oop.

PS2: si debo elegir / aprender / usar solo un enfoque, ¿es OOP o no? ¿por qué?

Si solo vas a aprender uno, debes elegir un campo diferente.

Debería aprender sobre los tipos y la encapsulación y todos los otros beneficios de OOP, y luego aprender cómo lograr esas mismas cosas usando un estilo funcional de programación.

Josh
fuente
+1 para el comentario sobre elegir un campo diferente si planea aprender un enfoque. Eso es una locura.
Mat Nadrofsky
1

OOP es definitivamente uno de los modelos de programación más dominantes en el mundo real.

Seamos realistas, incluso las personas que diseñan hardware digital, los propios diseñadores de chips, están haciendo una transición al dúo de SystemVerilog y SystemC. Estos son lenguajes de programación orientados a objetos.

¿Dónde no se utilizaría OOP? Bueno, si está codificando controladores de dispositivos, es difícil imaginar por qué necesitaría una programación genérica o una herencia múltiple O si está haciendo técnicas de programación funcional de IA lo hace mucho más fácil. Hay muchas otras situaciones también, basta decir que OOP es un lugar bastante poderoso para estar en un mundo de programación oligopolista.

Fanático23
fuente
1

Yo diría que no.

Entiendo que hay una gran cantidad de código que está escrito usando un lenguaje 'orientado a objetos', pero generalmente encuentro que el código es solo de procedimiento envuelto en clases. (No es que esto sea necesariamente algo malo). El código que he visto que está escrito para ser más OO en estos idiomas tiende a ser un horrible desastre de dependencias entre clases que generalmente no se puede mantener.

Se supone que OO se trata de pasar mensajes entre objetos completamente independientes, y lo vemos en el código de hoy, pero a un nivel mucho más amplio, es decir, vemos estos objetos implementados como dlls o ensamblados u objetos COM. 'Componentes' Los he escuchado descritos como.

Por lo tanto, creo que realmente no importa si se usa OO o no: si el código se puede mantener durante su vida útil, reutilizable en la medida en que fue diseñado y rápido de desarrollar, entonces no me importa si es puramente procesal o semi-orientado a objetos o totalmente orientado a objetos. Dudo que alguien pueda decirte si el estilo predominante es cualquiera de estos, pero me arriesgaría a adivinar que el estilo de procedimiento será el más común, incluso si está dividido en clases en lugar de funciones.

gbjbaanb
fuente
0

Creo que es importante diferenciar una solución obtenida aplicando un Enfoque Orientado a Objetos y una solución implementada USANDO el Paradigma Orientado a Objetos. Mi opinión sobre una buena pieza de software de orientación a objetos es combinar ambas soluciones. Si piensa en objetos y respeta las definiciones e interacciones de los objetos, y su problema podría adaptarse para usar esta estructura, entonces tendrá un código que es flexible y robusto. Pero si usa objetos para resolver un código usando un paradigma de procedimiento, terminará con una mezcla desagradable que no se aprovechará de los profesionales de Objetos.

Realmente prefiero que mi código esté orientado a objetos, y me he dado cuenta de que al principio podría ser un poco más molesto crear una buena estructura, pero cuando se trata de la flexibilidad y los requisitos de flash del cliente de hoy, creo que vale la pena esfuerzo.

Guiman
fuente
0

No pretendo saber los números exactos, ni siquiera hacer una suposición aproximada, pero hay muchos proyectos de programación que no involucran OOP. Yo trabajo con robots industriales. Los programas tienden a ser un código de procedimiento bastante simple y directo. El sistema operativo real del robot lo es aún más.

Muchas de nuestras "herramientas" que utilizamos están basadas en OOP, pero se ejecutan en PC y no en el controlador del robot. Estos incluyen editores, simulaciones y utilidades.

Jim C
fuente