Me he encontrado últimamente con algunas opiniones que dicen que el diseño/programación orientada a objetos no siempre se debe utilizar.
¿Conoces algunos casos de uso que no se beneficiarán y no deberían usar el diseño orientado a objetos?
Por ejemplo: hay algunos problemas (preocupaciones) que se beneficiarán de AOP.¿Cuándo está orientado a objetos no es la solución correcta?
Algunos problemas se expresan mejor usando otros paradigmas como la Programación funcional. Además, los paradigmas declarativos permiten un razonamiento formal más sólido sobre la corrección del código.Consulte Erlang para obtener un buen ejemplo de un idioma con ciertas ventajas que realmente no se pueden combinar con los lenguajes OO debido a la naturaleza fundamental del paradigma.
Ejemplos de dominios de problemas donde otros paradigmas de lenguaje se ajustan mejor son database queries (SQL), expert systems (Prolog, CLIPS etc.) o Statistical computing (R).
No es lo suficientemente bueno? No sé si puedo dar con un ejemplo de eso, pero sí sé que algunas aplicaciones REALMENTE simples podrían no ver ningún "beneficio" al principio de usar un modelo de diseño totalmente orientado a objetos. Sin embargo, si se trata de algo verdaderamente procesal y trivial, podría necesitar una nueva visita.
Las ventajas del diseño de OO son la capacidad de expansión y la capacidad de mantenimiento. Por lo tanto, no es de mucha utilidad cuando esas características no son necesarias. Estas serían aplicaciones muy pequeñas, para una necesidad muy específica a corto plazo. (cosas que consideraría hacer como un archivo por lotes o en un lenguaje de scripting)
Las preocupaciones transversales se benefician de la Programación Orientada a Aspectos (AOP). Por transversal, me refiero a la funcionalidad que podría beneficiar a varias partes de la aplicación y que realmente no pertenecen a un objeto en particular. El registro se da generalmente como un ejemplo. La seguridad podría ser otra. Por ejemplo, ¿por qué un objeto Persona debería saber algo sobre el registro o quién debería tener acceso a él?
Tenga en cuenta también que AOP y O-O son paradigmas complementarios y no son mutuamente excluyentes. – ConcernedOfTunbridgeWells
OOP podría ser un poco demasiado si está creando una aplicación increíblemente simple o una aplicación de procedimiento, como han dicho otros carteles. Además, no creo que AOP necesariamente tenga que reemplazar OOP, en todo caso ayuda a reforzar un buen diseño de OOP.
No quise decir reemplazarlo. Lo uso para completarlo. Sin embargo, ¿hay más ejemplos como este? –
OOP y AOP no son mutuamente exclusivos, son complementarios.
En cuanto a OO, sin duda hay casos en que es menos aplicable. Si no hubiera todo lo que tendríamos es OO idiomas. Para tareas puramente numéricas, muchas personas todavía prefieren Fortran. Los lenguajes funcionales son útiles cuando se trata de simultaneidad y paralelismo.
Además, cuando su aplicación es principalmente solo una base de datos con una GUI (como una aplicación CRM, por ejemplo) OO no es muy útil, aunque podría usar un lenguaje OO para compilarla.
Debo ir de visita en wikipedia y leer sus artículos sobre diferentes tipos de lenguajes de programación.
Decir que un tipo de programación "no es lo suficientemente bueno" no tiene ningún sentido. Cada tipo tiene un propósito. No puedes compararlos. No están hechos para hacer lo mismo.
Uno que fácilmente viene a la mente ... Aplicaciones web de base de datos.
En tal escenario, tiene más sentido conformarse a un marco aceptado ... en lugar de buscar un buen diseño de OOP. p.ej. si tiene que hacer algún tipo de consulta compleja con JOIN y ORDER BYs ... SQL pateará el objeto a tope.
Elija la solución en función del problema ... en lugar de resolver el problema hasta que se adapte a una solución.
En mi experiencia, uno de los lugares que no se beneficia del diseño OO es en los sistemas embebidos de gama baja. Hay una cierta cantidad de sobrecarga requerida para hacer OO y hay momentos en que no puede pagar esta sobrecarga. En una PC estándar, la sobrecarga es tan mínima que ni siquiera vale la pena considerarla, sin embargo, en los sistemas embebidos de baja potencia, esa sobrecarga puede ser significativa.
No me molestaría con OOP si el lenguaje de programación que está usando no le permite usar fácilmente OOP. Usamos un BDL en mi lugar de trabajo que se hace para ser procesal. Una vez traté de hacer un poco de OOP, y bueno, eso fue solo un gran ¡Uy! No debería haber molestado.
El principio fundamental que hay que entender aquí es que no existe una metodología, paradigma o enfoque universal que pueda aplicarse a todos los dominios problemáticos. Por lo general, están diseñados para atender un conjunto particular de problemas y no pueden optimizarse para otros dominios.
Es como un algoritmo para un tipo típico de problema (por ejemplo, ordenamiento). No puede haber un algoritmo universal que sea aplicable a todos los posibles escenarios o conjuntos de datos.
Lo mismo para OOP. No lo aplicaría a un problema que está esencialmente relacionado con la IA y que se puede resolver mejor usando programación declarativa. Ciertamente no lo aplicaría para desarrollar controladores de dispositivos que requieran el máximo rendimiento y velocidad.
Cada vez que no se le ocurre una buena razón para OO, es un buen momento para evitarlo. (Suena gracioso, pero hablo en serio.)
La programación orientada a objetos es una buena solución si haces un buen diseño.
Haciendo eco de Nigel, SQL parece ser casi implícitamente incompatible con cualquier tipo de abstracción (incluidas las subconsultas y funciones).
Bueno, OOP no es especialmente ortogonal a nada (excepto quizás otras formas de obtener polimorfismo) entonces ... eh ... lo que sea.
OOP es apropiado siempre que necesite agrupar dos o más elementos de información. –
AOP no es ortogonal a OO. – Marcin