¿Para qué problemas la programación orientada a objetos no es una buena opción? [cerrado]

Algo inspirado por esta pregunta: ¿para qué problemas comunes la programación funcional no es adecuada? - Sin embargo, una pregunta que siempre quise, pero tenía demasiado miedo de hacerla.

He estado en ... bueno, llamémoslo desarrollo de software de ingeniería prácticamente toda mi vida, y en todo ese tiempo, aunque OO siempre había estado allí (bueno, la mayor parte del tiempo) nunca tuve la necesidad de usar "sus formas", ni aprender ese paradigma. Siempre hemos utilizado estructuras de programas bastante simples, rutinas / funciones / módulos y, aunque es contrario a las mejores prácticas actuales que administran esos programas (programas de hasta aproximadamente 300k LOC, nada demasiado grande) nunca demostraron ser difíciles, y mucho menos imposibles.

Así que quería preguntarle, ¿cuáles serían los problemas para los cuales el paradigma orientado a objetos no sería una buena opción? En comparación con la programación procesal?

La programación orientada a objetos es programación procesal. Lo que hace que OO esté orientado a objetos es, como Robert Harvey menciona en un comentario, que OO abstrae datos de una manera particular (a saber: agrupar las funciones que operan en una estructura con esa estructura).

William Cook explica muy bien la diferencia entre objetos y tipos de datos abstractos.

Entonces, a riesgo de sonar fácil, diría que los objetos no son adecuados para cuando necesita extender fácilmente (la cantidad de) operaciones que se realizan en sus datos, y no necesita tener implementaciones diferentes de sus datos. Dicho esto, hay cosas que puedes hacer para unir a los dos.

El valor principal de OO es que proporciona el desacoplamiento entre los componentes de su sistema, lo que facilita la escritura del código DRY y la adaptación a los tipos específicos de cambio que planea en su diseño. El costo es que agrega capas de indirección, lo que puede hacer que el código sea más difícil de razonar, menos eficiente y más difícil de modificar de manera imprevista (las formas que no se ven favorecidas por el desacoplamiento que proporciona su diseño). Por lo tanto, es una pérdida de tiempo para cualquier subproblema donde no necesita el desacoplamiento que proporciona. Específicamente, es una pérdida de tiempo si puede escribir fácilmente código DRY sin él y no anticipa ningún cambio de requisitos específicos que se beneficiaría del desacoplamiento fuerte que proporciona OO.

concurrencia: el mecanismo de bloqueo parece problemático; solo algunos desarrolladores muy buenos se ponen a trabajar en la parte de subprocesos de los proyectos

extendido: no sé cuán comprensibles son los lenguajes OO actuales. Solo sé que Java es malo. por lo tanto, los DSL (lenguajes específicos del dominio) deben implementarse como Frameworks. Clojure por otro lado (que es funcional), tiene macros.

La mayoría de los programadores, conocedores o no, utilizan conceptos como abstracción, ocultación de información e interfaces en su código. Los lenguajes OO simplemente lo hacen más fácil ya que estos conceptos ya están integrados. No tienes que inventarlos tú mismo.

Un algoritmo central como el qsort()utiliza abstracciones para la comparación de objetos arbitrarios. fread()utiliza una interfaz para abstraer los detalles de la transmisión, etc.

Desde ese punto de vista, me resulta difícil encontrar algún problema en particular que se resuelva mejor con un enfoque que no sea OO.

Creo que al construir sistemas que combinan otros sistemas a través de apis web (rest, xmlprc, plain curl / wget) puede escribir contenedores OO, pero es claramente una conveniencia. Si el servicio web que se utilizará es simple, y es solo una cuestión de una o dos líneas, entonces OO es demasiado. Si, por otro lado, termina envolviendo una API web compleja (como Amazon AWS, por ejemplo), entonces es bueno tener una biblioteca de envoltura (como boto en python para AWS).

Pensamientos?

Los lenguajes orientados a objetos PURE no son adecuados para muchos casos. Porque hay algunos criterios que deben cumplirse para ser lenguaje puro orientado a objetos. Ver-
/programming/250062/what-is-meant-by-the-term-true-object-orientation/250098#250098

Pero los lenguajes de programación más utilizados son multi-paradigmáticos. Incorporan muchas características que no son OO para encontrar varios tipos de problemas de programación y desarrollo. C ++, C #, Java o Ruby tienen funcionalidades que no son OO. Por lo tanto, pueden enfrentar problemas en los que pure-OO no es bueno.

La programación orientada a objetos se puede utilizar para modelar su dominio. Las clases se pueden usar para representar el estado y el comportamiento de entidades, agregados, colaboraciones, servicios dentro de su modelo de dominio. Además, las invocaciones de métodos y protocolos entre los objetos pueden modelar las relaciones dinámicas entre entidades.

He encontrado que es una forma útil de producir un modelo DRY que pueda representar limpiamente las reglas y el comportamiento de su aplicación de una manera que esté desacoplada de problemas técnicos (como el uso de una base de datos, una cola de mensajes o el de hecho es una aplicación web). Un buen libro sobre el tema es Diseño impulsado por dominio

¡Una cosa importante a tener en cuenta aquí es que las "entidades" que mencioné anteriormente no tienen que mapearse en objetos del mundo real! Pueden representar partes abstractas del dominio de su aplicación para.

Entonces, si eso es lo que hace la programación Orientada a Objetos; ¿para qué no es bueno? Bueno, cualquier cosa donde el modelo de dominio no pueda expresarse bien como objetos. Por ejemplo, algunos programas matemáticos (estadísticos, lógicos, etc.) o técnicos (por ejemplo, un compilador) se pueden expresar mejor en diferentes estilos. He descubierto que para las aplicaciones de flujo de trabajo empresarial, una combinación de OO y técnicas DSL personalizadas ha sido muy efectiva al permitirnos modelar los tipos de relaciones y eventos que ocurren en el proceso comercial. Para la verificación del programa y la verificación de pruebas automatizadas, a menudo se utiliza un enfoque funcional , porque sus funciones puras permiten un razonamiento matemático más directo.