¿OOP tiene sentido para guiones pequeños?

La programación orientada a objetos, si bien es útil para representar sistemas como objetos del mundo real (y con suerte hacer que los grandes sistemas de software sean más fáciles de entender) no es la bala de plata para todas las soluciones (a pesar de lo que algunas personas enseñan).

Si su sistema no se beneficia de lo que proporciona OOP (cosas como la abstracción de datos, encapsulación, modularidad, polimorfismo y herencia), entonces no tendría sentido incurrir en toda la sobrecarga de hacer OOP. Sin embargo, si usted encuentra que como su sistema crece estas cosas se convierten en una preocupación más grande para usted, entonces es posible que desee considerar la posibilidad de pasar a una solución de OOP.

Editar: Como actualización, es posible que desee dirigirse a Wikipedia para leer los artículos sobre varias críticas de OOP. Recuerda que OOP es una herramienta, y al igual que no usarías un martillo para todo, OOP no debe usarse para todo. Considere la mejor herramienta para el trabajo.

Si planea usar el script de forma independiente, entonces no. Sin embargo, si planea import y reutilizar parte de ella, entonces sí. En el segundo caso, es mejor escribir algunas clases que proporcionen la funcionalidad que se requiere y luego tener una ejecución condicional (if __name__=='__main__':) con código para ejecutar la versión "script" del script.

Uno de los hábitos desafortunados desarrollados con oop es Objectophrenia - la ilusión de ver objetos en cada pieza de código que escribimos.

La razón por la que eso sucede se debe a nuestra ilusión de creer en la existencia de un teorema de objetos unificados.

Cada pieza de código que escribes, empiezas a verlo como una plantilla para objetos y cómo encajan en nuestro esquema personal de cosas. A pesar de que podría ser una pequeña tarea a mano, nos sentimos tentados por la pregunta - ¿ es esto algo que ¿podría colocarlo en mi repositorio de clases que también podría usar para el futuro? ¿Veo un patrón aquí con el código que he escrito anteriormente y con el código que mi clarividencia objeto me dice que voy a escribir un día? ¿Puedo estructurar mi tarea actual en uno de estos patrones?

Es un hábito molesto. Con frecuencia, es mejor no tenerlo. Pero cuando encuentras que cada bit de código que escribes de alguna manera cae en patrones y refactorizas / realineas esos patrones hasta que cubre la mayor parte de sus necesidades, usted tiende a obtener una sensación de satisfacción y logro.

Los problemas comienzan a aparecer cuando un programador se delira (trastorno obsesivo compulsivo orientado a objetos) y no se da cuenta de que hay excepciones a los patrones y tratar de sobre-manipular patrones para cubrir más casos es incorrecto. Es como mi obsesión de la infancia con tratar de cubrir un pedazo de pan completamente con mantequilla o mermelada todas las mañanas desayunaba. Que a veces, es mejor deje atrás la percepción orientada a objetos y simplemente realice la tarea en cuestión de forma rápida y sucia.

El adagio industrial aceptado de 80-20 podría ser una buena medida. Usando este adagio de una manera diferente a la que se percibe normalmente, podríamos decir que el 80% de las veces tiene una percepción orientada a objetos. el 20% del código de tiempo es rápido y sucio.

Estar inmerso por objetos, pero al final tienes que resistir que te consuma.

Probablemente no hayas hecho suficiente programación todavía porque si lo has hecho, verías todos los patrones que has hecho y también empezarás a creer en patrones que aún tienes que aplicar. Cuando empiezas a ver tales visiones objectophrenia, es hora de tener cuidado de no ser consumido por ellos.

Mi experiencia es que cualquier guion puramente procedimental más largo que unas pocas docenas de líneas se vuelve difícil de mantener. Por un lado, si estoy configurando o modificando una variable en un lugar y la uso en otro lugar, y esos dos lugares no pueden caber en una sola pantalla, los problemas seguirán.

La respuesta, por supuesto, es ajustar el alcance y hacer que las diferentes partes de su aplicación estén más encapsuladas. OOP es una manera de hacer eso, y puede ser una manera útil de modelar su entorno. Me como OOP, a medida que encuentro que puedo saltar mentalmente de pensar en cómo funcionará el interior de un objeto en particular, a pensar en cómo los objetos trabajarán juntos, y me mantengo más cuerdo.

Sin embargo, OOP no es ciertamente la única manera de encapsular mejor su código; otro enfoque sería un conjunto de funciones pequeñas y bien nombradas con entradas y salidas cuidadosamente definidas, y un script maestro que llame a esas funciones según corresponda.

¿Me estoy perdiendo algo al no esforzarme más por usar objetos, o el OOP simplemente no tiene mucho sentido para pequeños scripts?

Los objetos te compran encapsulación y reutilización (a través de la herencia). Tampoco es probable que sea terriblemente útil cuando se escriben guiones pequeños. Cuando haya escrito una colección de scripts similares o se encuentre cambiando repetidamente sus scripts, entonces tal vez debería considerar dónde podrían ayudar los objetos.

OOP es una herramienta para manejar la complejidad en el código, 50-250 líneas de código rara vez son complicadas. La mayoría de los guiones que he escrito son principalmente de procedimiento. Así que sí, para pequeños scripts simplemente vaya con la programación procedimental.

Tenga en cuenta que para scripts significativamente complicados OOP puede ser más relevante, pero todavía no hay una regla dura y rápida que dice usar OOP para ellos. Es una cuestión de preferencia personal entonces.

Utilice la herramienta correcta para el trabajo correcto. Para scripts pequeños que no requieren estructuras de datos y algoritmos complejos, es probable que no se utilicen conceptos orientados a objetos.

En su caso yo diría que OOP sería útil solo si hace que los scripts sean más legibles y comprensibles. Si no, probablemente no necesite molestarse.

OOP es solo otro paradigma. Muchos problemas se pueden resolver usando tanto procedural como OOP.

Uso OOP cuando veo una clara necesidad de herencia en el código que estoy escribiendo, es más fácil administrar el comportamiento común y los atributos comunes.

A veces hace que sea fácil de entender y administrar. Incluso si el código es pequeño.

Otro beneficio de OOP es comunicar la intención (ya sea a otros desarrolladores, gerentes o a ti mismo en algún momento en el futuro). Si el guion es lo suficientemente pequeño como para que pueda comunicarse completamente en un par de oraciones, probablemente no sea necesario, en mi opinión.

Usar OOP para unos cientos de líneas de código rara vez tiene sentido. Pero si su script es útil, probablemente crecerá bastante rápido porque se agregarán nuevas características. Si este es el caso, es mejor comenzar a codificar la forma de OOP que pagará a largo plazo.

OOP es acerca de lo que se obtiene si se agrega polimorfismo en la parte superior de la programación modular.
Este último de ambos promueve un bajo acoplamiento, encapsulación, separación de responsabilidades y algunos otros conceptos, que suelen producir código, que es corto, expresivo, mantenible, flexible, extensible, reutilizable y robusto.

Esto no es tanto una pregunta sobre el tamaño, sino sobre la duración del ciclo de vida del software. Si escribes cualquier código, tan corto como sea, siempre y cuando sea lo suficientemente complejo como para si no desea reescribirlo, cuando cambien sus requisitos, es importante que cumpla con los criterios mencionados anteriormente.

OOP facilita la programación modular ya que ha establecido soluciones para implementar los conceptos promovidos por la programación modular, y que el polimorfismo permite un acoplamiento realmente bajo a través de la inyección de dependencias.

Personalmente me parece más fácil usar OOP para lograr la modularidad (y la reutilización en particular), pero supongo que es una cuestión de hábito.

Para ponerlo en una oración. OOP no le ayudará en la solución de un problema dado mejor, que la programación de procedimiento, sino que produce una solución, que es más fácil de aplicar a otros problemas.

Realmente depende de lo que el script es, de lo que está haciendo y de cómo piensas sobre el mundo.

Personalmente, después de que un script haya pasado de 20 a 30 líneas de código, generalmente puedo encontrar una manera de que el OOP tenga más sentido para mí (especialmente en Python).

Por ejemplo, digamos que estoy escribiendo un script que analiza un archivo de registro. Bueno, conceptualmente puedo imaginar esta máquina "log parser"... Puedo tirar todas estas hojas de papel y las clasificará, cortará partes de algunas páginas y pégalos en otro y, finalmente, pásame un buen informe.

Entonces empiezo a pensar, bueno, ¿qué hace este analizador? Bueno, en primer lugar él es (sí, el analizador es un él. No se cuántos de mis programas son mujeres, pero este es definitivamente un chico) va a leer las páginas, así que necesitaré un método llamado page reader. Luego va a encontrar todos los datos referentes al nuevo proceso de Frobnitz que estamos usando. Luego moverá todas las referencias sobre el proceso Frobnitz para que aparezcan junto al gráfico del Conejo de Pascua. Así que ahora necesito un método findeasterbunny. Después de que haya hecho eso, entonces va a tomar el resto de los registros, eliminar cada 3ra palabra, e invertir el orden del texto. Así que necesitaré un thirdwordremover y un textreversal método, también. Así que una clase shell vacía se vería así:

class LogParser(Object):
    def __init__(self):
         #do self stuff here
    def pageReader(self):
         #do the reading stuff here, probably call some of the other functions
    def findFrobnitz(self):
         pass
    def findEasterBunny(self):
         pass
    def thirdWordRemover(self):
         pass
    def textReversal(self):
         pass

Ese es un ejemplo realmente artificial, y honestamente probablemente no es una situación para la que usaría OOP... pero realmente solo depende de lo que es más fácil para mí comprender en ese momento en particular en tiempo.

En primer lugar - ¿qué quiere decir con objetos? En Python las funciones son objetos y lo más probable es que los estés usando. :)

Si por objetos te refieres a clases e instancias de los mismos, entonces diría algo obvio: no, no hay razón para decir que usarlos está haciendo que tu código sea mejor por sí mismo. En scripts pequeños no va a haber ningún apalancamiento proveniente del sofisticado diseño OO.

"Script" significa "secuencial" y "procedimental". Es una definición.

Todos los objetos con los que trata el script son objects bueno objects objetos. Toda programación involucra objetos. Los objetos ya existen en el contexto en el que estás escribiendo tu script.

Algunos lenguajes permiten identificar claramente los objetos. Algunos idiomas no identifican claramente los objetos. Los objetos están siempre allí. Es una cuestión de si el lenguaje lo deja claro o oscurecer.

Dado que los objetos están siempre allí, me parece útil usar un lenguaje que permita una clara identificación de los objetos, sus atributos, métodos y relaciones. Incluso para "scripts" cortos, encuentro que los objetos explícitos y un lenguaje OO ayudan.

El punto es este.

No hay una distinción útil entre "procedural", "script" y "OO".

Es simplemente un cambio de énfasis. Los objetos están siempre allí. El mundo es inherentemente orientado a objetos. La verdadera pregunta es " ¿Usas un lenguaje que hace explícitos los objetos?"

Como alguien que hace un montón de scripts, si tienes la idea de que tu código puede en algún momento ir más allá de 250 línea empezar a ir oop. Uso mucho vba y vbscript y estaría de acuerdo en que cualquier cosa por debajo de 100 líneas suele ser bastante sencillo y tomarse el tiempo para planificar un buen diseño de oop es solo un desperdicio.

Dicho esto, tengo un guión que llegó a más de 500 líneas y mirando hacia atrás, porque no lo hice, se convirtió rápidamente en un desastre de espaguetis. tan ahora cualquier cosa más de 200 líneas me aseguro de tener un buen plan de oop antes de tiempo