¿Cuándo usamos realmente la programación orientada a objetos? [cerrado]

Estoy escribiendo un programa en Python, que básicamente manipula cadenas, y me preguntaba si debería hacerlo utilizando los principios OOP o no. El cliente me dijo que no le importa el código, solo quiere que se haga .

Sé que el código orientado a objetos no es por definición más limpio y, por el contrario, el código que no es OO no es, por definición, malo. La pregunta que estoy haciendo podría estar más o menos basada en la opinión, pero podría haber algunas reglas que desconozco.

Más información sobre lo que hay que hacer:

• analizar un .csvarchivo y procesar los datos en función de un archivo de configuración (las columnas pueden ser diferentes, como en el número de columnas o los datos que contienen)
• use los datos procesados ​​anteriores para crear nuevos datos formateados personalizados (o múltiples archivos basados ​​en algunos de los valores anteriores)
• use los últimos datos formateados para crear un archivo XML.
• dividir el archivo XML en varios XMLcorreos electrónicos según su contenido
• la aplicación debe estar basada en CLI
• Por supuesto, hay otras cosas como: registrar algunos eventos, analizar argumentos de la CLI, etc.

Ahora, esta no es una aplicación grande / difícil, y también está casi terminada, pero durante todo el proceso de desarrollo me preguntaba si esto debería hacerse usando OOP o no.

Entonces, mi pregunta sería: ¿cómo saben / deciden cuándo usar OOP en una aplicación?

Python es un lenguaje de paradigmas múltiples, lo que significa que puede elegir el paradigma más apropiado para la tarea. Algunos lenguajes como Java son OO de paradigma único, lo que significa que obtendrá dolores de cabeza si intenta usar cualquier otro paradigma. Los carteles que dicen "siempre use OO" probablemente provengan de un fondo en ese idioma. ¡Pero afortunadamente tienes una opción!

Observo que su programa es una aplicación CLI que lee algunas entradas (csv y archivos de configuración) y produce algo de salida (archivos xml), pero no es interactiva y, por lo tanto, no tiene una GUI o API con estado. Tal programa se expresa naturalmente como una función de entrada a salida, que delega a otras funciones para subtareas.

OO, por otro lado, se trata de encapsular el estado mutable y, por lo tanto, es más apropiado para aplicaciones interactivas, GUI y API que exponen el estado mutable. No es casualidad que OO se haya desarrollado en paralelo con las primeras GUI.

OO tiene otra ventaja, ya que el polimorfismo le permite una arquitectura más débilmente acoplada, donde diferentes implementaciones de la misma interfaz pueden sustituirse fácilmente. Combinado con la inyección de dependencias, esto puede permitir la carga basada en la configuración de dependencias y otras cosas interesantes. Sin embargo, esto es principalmente apropiado para aplicaciones muy grandes. Para un programa del tamaño de lo que describe, sería una sobrecarga excesiva sin beneficio aparente.

Además de las funciones que realmente leen y escriben los archivos, la mayor parte de su lógica se puede escribir como funciones libres de efectos secundarios que toman algo de entrada y devuelven alguna otra salida. Esto es eminentemente fácil de probar, mucho más simple que probar unidades OO donde necesita burlarse de dependencias y demás.

En pocas palabras: sugiero un montón de funciones divididas en módulos para la organización, pero no objetos.

Considere un botón en una GUI. Tiene estado (es tamaño, color, posición, etiqueta, etc.). Pueden sucederle cosas (se hace clic, se debe volver a dibujar, etc.). En tales situaciones, modelarlo como un objeto tiene sentido. Como objeto, puede contener su estado, un conjunto de acciones que se pueden realizar en él (métodos) y puede notificar a otras partes de la aplicación que le han sucedido cosas disparando eventos.

OOP es una herramienta excelente para manejar GUI y otras situaciones en las que partes del sistema tienen un estado volátil.

Otras situaciones, como la que usted describe, en la que los datos se leen desde una fuente, se procesan y se escriben en un destino, se manejan bien con un enfoque diferente: la programación declarativa (o función). El código declarativo para el procesamiento de datos tiende a ser más fácil de leer y más corto que las soluciones OOP.

Así como un martillo y una sierra son herramientas poderosas cuando se usan correctamente, también lo son las técnicas de programación orientadas a objetos y declarativas. Probablemente podrías clavar un clavo en un trozo de madera con el mango de una sierra. Del mismo modo, puedes romper un trozo de madera por la mitad con un martillo. Del mismo modo, puede crear una GUI con solo funciones y procesar datos con objetos. Sin embargo, cuando las herramientas se usan correctamente, los resultados son más limpios y simples.

La regla general que uso es que si tengo mucho estado o necesito interacción del usuario, uso objetos; de lo contrario, uso (puro y de orden superior, cuando sea posible) funciones.

La programación orientada a objetos agrega cuatro nuevas herramientas a su arsenal:

1. Encapsulamiento
2. Abstracción
3. Herencia
4. Polimorfismo

Usaría OOP en su aplicación cuando haya crecido lo suficiente y sea lo suficientemente compleja como para beneficiarse de estas herramientas.

Esta pregunta me parece un poco confusa. Si lo está escribiendo en Python, seguramente usará objetos. Cuando abre un archivo, devuelve un objeto. Cuando produce el resultado, devuelve un objeto iterador. Cada función que crea es un objeto. Cuestionar el valor de OO en las aplicaciones de Python parece extraño, por decir lo menos.

Según los comentarios aquí, sí, Python admite paradigmas funcionales, pero está principalmente basado en objetos. El lenguaje en sí y las bibliotecas incorporadas están orientadas alrededor de los objetos. Sí, es compatible con lambda (al igual que Java y cualquier otro número de idiomas típicamente descritos como OO), pero es intencionalmente simplista en comparación con un verdadero lenguaje funcional.

Quizás estas distinciones en torno al diseño OO y el diseño funcional se están volviendo obsoletas. Si creo, tomo una función polimórfica en un Objeto * diseñado por OO y le paso un puntero a esa función en un objeto como parámetro para la función funcionalmente diseñada *, ¿es OO o es funcional? Creo que es a la vez un enfoque realmente efectivo para resolver problemas.

Creo que la verdadera pregunta es "¿cuándo debería comenzar a diseñar sus propias clases en lugar de simplemente crear un módulo con funciones?" Creo que la respuesta correcta para eso es: cuando ayuda a simplificar la solución. Daría la misma respuesta básica para cualquier lenguaje orientado a objetos.

* la redundancia es intencional: no quiero ser acusado aquí de suponer que los objetos son OO o que las funciones son funcionales.

Una de las cosas más importantes de la programación orientada a objetos es que en lugar de razonar sobre el flujo del programa, comienza a razonar sobre el estado.

Muchas veces veo el objeto, veo los métodos, pero lo que también veo es que el pensamiento impulsor detrás del código es el flujo en lugar del estado.

Y una vez que razona sobre el estado, es fácil construir un buen código OOP porque tan pronto como su código se vuelve demasiado complejo, nota que ya no puede razonar sobre su estado y sabe que necesita refactorizar.

Considere su ejemplo: desea analizar un archivo csv. De dónde viene: un archivo en el disco. Lo carga, lo guarda en la memoria y lo analiza. Ahora viene su cliente: oye, también quiero analizar archivos de la web. Así que está contento porque creó una interfaz agradable para cargar su archivo y solo tiene que hacer que el código que lo obtiene de la web y el resto de su programa permanezca exactamente igual.

Y lo bueno es: puedes probar eso.

En términos simples:

• Puede usar OOP o no OOP en cualquier tipo de proyectos que desee.
• OOP no es la panacea, pero ayuda a gestionar la complejidad.
• Va más allá de la modularidad, se trata de compartimentación. Piense en los diferentes compartimientos que tiene un barco para retener la flotabilidad si el casco está dañado.
• OOP es una forma de administrar dependencias para que los errores puedan ser más fáciles de rastrear, ya que solo hay un conjunto definido de formas en que los diferentes componentes de un programa pueden comunicarse entre sí.
• En un programa hay muchas cosas que funcionan: variables, constantes, métodos, archivos, parámetros, funciones, módulos, etc. Pueden interactuar entre sí de maneras que a veces pueden ser impredecibles. OOP es un conjunto de principios que reducen la cantidad de formas en que las cosas pueden interactuar entre sí. No está obligado a usar OOP para hacer eso, pero ayuda.

Dicho esto, hay otros factores a tener en cuenta:

• ¿Son sus programadores competentes en OOP / OOD?
• ¿Sus programadores dominan un lenguaje OOP?
• ¿Crees que el software se volverá complejo con el tiempo?
• ¿Planea escalar o reutilizar código en el futuro?
• ¿Crees que tu "diseño" puede convertirse en un activo? es decir, ¿podrá aprovecharlo para crecer o como base para futuros proyectos?

No me malinterpreten: puede lograr todo eso sin usar OOP, pero con OOP será más fácil.

Pero...

Si su equipo no es experto en OOP / OOD y no tiene experiencia en esa área, vaya con los recursos que tiene.

Entonces, mi pregunta sería: ¿cómo saben / deciden cuándo usar OOP en una aplicación?

Úselo siempre. Una vez que esté acostumbrado a usarlo, lo usará para todo. Es una excelente manera de garantizar una buena abstracción entre las capacidades y su uso, lo cual es un beneficio significativo para el mantenimiento. Lo usamos, por ejemplo, para

• los objetos de estructura de datos pequeños, porque estos son a menudo polimórficos, por ejemplo, y la estructura de datos intermedia después de analizar algo a menudo tiene múltiples entidades pequeñas, que tienen un comportamiento común y, sin embargo, también están especializadas. Estos son un gran caso de uso para una clase base o interfaz común, con implementaciones y comportamientos especializados, es decir, una jerarquía de clases (polimorfismo).

• registro, como ejemplo, porque facilita la sustitución de un registrador diferente

• grandes piezas de estructura de programa, porque evoca múltiples concurrentes, y tal vez aproveche los procesadores de múltiples CPU. Por ejemplo, un servidor web puede usar trivialmente múltiples manejadores de solicitudes concurrentes, debido a los objetos.

Facilita la refactorización y la reutilización, como mencioné, alienta una buena abstracción, todo lo cual facilita el mantenimiento. OOP debe ser aceptado y utilizado todo el tiempo. Una buena programación de OOP evita métodos estáticos y / o datos estáticos, y usa objetos para todo.

La programación orientada a objetos proporciona herramientas para crear un marco. Estas herramientas son encapsulación, abstracción, herencia y polimorfismo. Estas ideas lo ayudarán a dividir su programa en dos secciones.

Cómo: esta es la parte del marco de trabajo de su código, donde crea algún tipo de abstracción, decide cómo funcionan sus bloques en general y cómo interactúa con otros bloques.

Qué hacer: esta parte es donde los bloques hacen el trabajo en sí. Aquí las clases se derivan de las clases base creadas en la sección "Cómo".

Uno puede beneficiarse enormemente de OOPS

1. si puede reutilizar un marco existente y solo tiene que implementar detalles específicos en la sección "qué hacer".
2. La funcionalidad que se está implementando para el proyecto actual es genérica / de uso común y otros proyectos / proyectos futuros pueden obtener beneficios del marco que se crea durante el desarrollo del proyecto actual.
3. Desglosando grandes proyectos en patrones comúnmente conocidos para resolver un gran problema.
4. Use OOPS incluso para proyectos pequeños para acostumbrarse a usarlo y esté listo cuando surjan 1 a 3 tipos de problemas