python - oriented - ¿Tiene sentido OOP para pequeños scripts?
python object oriented programming pdf (17)
Principalmente escribo pequeños scripts en python, alrededor de 50 a 250 líneas de código. Usualmente no uso ningún objeto, solo programación procesal directa.
Sé lo básico de OOP y he usado objetos en otros lenguajes de programación anteriormente, pero para los scripts pequeños no veo cómo los objetos los mejorarían. Pero tal vez esa sea solo mi experiencia limitada con OOP.
¿Me estoy perdiendo algo al no esforzarme más por usar objetos, o OOP simplemente no tiene mucho sentido para los scripts pequeños?
¿Me estoy perdiendo algo al no esforzarme más por usar objetos, o OOP simplemente no tiene mucho sentido para los scripts pequeños?
Los objetos compran encapsulación y reutilización (a través de la herencia). Es probable que ninguno sea terriblemente útil cuando se escriben pequeños guiones. Cuando haya escrito una colección de scripts similares o se encuentre cambiando repetidamente sus scripts, tal vez debería considerar dónde pueden ayudar los objetos.
"Script" significa "secuencial" y "de procedimiento". Es una definicion
Todos los objetos de los que trata su script son, bien, objetos. Toda la programación involucra objetos. Los objetos ya existen en el contexto en el que está escribiendo su script.
Algunos idiomas le permiten identificar claramente los objetos. Algunos idiomas no identifican claramente los objetos. Los objetos están siempre ahí. Es una cuestión de si el lenguaje lo hace claro u oscuro.
Dado que los objetos están siempre allí, encuentro que es útil usar un lenguaje que permita una identificación clara de los objetos, sus atributos, métodos y relaciones. Incluso para los "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 ahí. El mundo está inherentemente orientado a objetos. La verdadera pregunta es "¿Utiliza un lenguaje que hace que los objetos sean explícitos?"
En primer lugar, ¿qué quieres 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 es mejorar tu código por sí mismo. En scripts pequeños, no habrá ningún apalancamiento proveniente del diseño sofisticado de OO.
En su caso, diría que la OOP sería útil solo si hace que los scripts sean más legibles y comprensibles. Si no, probablemente no necesites molestarte.
La Programación Orientada a Objetos, aunque útil para representar sistemas como objetos del mundo real (y, con suerte, hacer que el sistema de software grande sea más fácil de entender) no es la bala de plata para cada solución (a pesar de lo que algunas personas enseñan).
Si su sistema no se beneficia de lo que proporciona la OOP (cosas como la abstracción de datos, la encapsulación, la modularidad, el polimorfismo y la herencia), entonces no tendría sentido incurrir en toda la sobrecarga de realizar la POO. Sin embargo, si encuentra que a medida que su sistema crece, estas cosas se convierten en una preocupación mayor para usted, entonces puede considerar cambiarse a una solución OOP.
Edición : Como actualización, es posible que desee dirigirse a Wikipedia para leer los artículos sobre varias críticas de la POO . Recuerde que OOP es una herramienta, y al igual que usted no usaría un martillo para todo, OOP no debería usarse para todo. Considera la mejor herramienta para el trabajo.
Mi experiencia es que cualquier guión puramente procedural de más de 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 usándola en otro lugar, y esos dos lugares no caben en una sola pantalla, los problemas seguirán.
La respuesta, por supuesto, es restringir el alcance y hacer que las diferentes partes de su aplicación estén más encapsuladas. La OOP es una forma de hacerlo y puede ser una forma útil de modelar su entorno. Me gusta la POO, ya que me parece que puedo saltar mentalmente de pensar cómo funcionará el interior de un objeto en particular, a pensar cómo funcionarán los objetos juntos, y me mantengo más sano.
Sin embargo, la POO no es la única forma de hacer que su código esté mejor encapsulado; 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.
OOP es solo otro paradigma. Se pueden resolver muchos problemas utilizando procedimientos u 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.
OOP es una herramienta para administrar 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 solo vaya con la programación de procedimientos.
Tenga en cuenta que para scripts significativamente complicados, la OOP puede ser más relevante, pero aún no existe una regla estricta que diga usar OOP para ellos. Es una cuestión de preferencia personal entonces.
OOP se trata de lo que obtienes si agregas polimorfismo a la programación modular.
El último de ambos promueve el acoplamiento bajo, la encapsulación, la separación de responsabilidades y algunos otros conceptos, que generalmente producen código, que es breve, expresivo, mantenible, flexible, extensible, reutilizable y robusto.
Esta no es tanto una pregunta sobre el tamaño, sino sobre la duración del ciclo de vida del software. Si escribe cualquier código, por breve que sea, siempre que sea lo suficientemente complejo como para que no desee volver a escribirlo, cuando cambien sus requisitos, es importante que cumpla con los criterios mencionados anteriormente.
La programación orientada a objetos hace que la programación modular sea más fácil, ya que ha establecido soluciones para implementar los conceptos promovidos por la programación modular, y ese polimorfismo permite un acoplamiento realmente bajo a través de la inyección de dependencia.
Personalmente, me parece más sencillo utilizar la POO para lograr la modularidad (y la reutilización en particular), pero supongo que eso es una cuestión de hábito.
Para ponerlo en una frase. La OOP no lo ayudará a resolver mejor un problema dado que a la programación de procedimientos, sino que brinda una solución que es más fácil de aplicar a otros problemas.
Otro beneficio de la POO es comunicar la intención (ya sea a otros desarrolladores, administradores o a ti mismo en algún momento en el futuro). Si el guión es lo suficientemente pequeño como para que se pueda comunicar completamente en un par de oraciones, entonces, en mi opinión, probablemente no sea necesario OOP.
Realmente depende de qué es el guión y qué piensas del mundo.
Personalmente, después de que un script supere las 20-30 líneas de código, generalmente puedo encontrar una forma en la que la POO 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 de "analizador de registro" ... Puedo tirar todas estas hojas de papel en ella y las clasificará, cortaré algunas páginas y las pegaré en otra y finalmente me entregará un informe agradable.
Entonces empiezo a pensar, bueno, ¿qué hace este analizador? Bueno, primero que nada (sí, el analizador es un él. No sé 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 página lector. Luego encontrará todos los datos referentes al nuevo proceso de Frobnitz que estamos usando. Luego, moverá todas las referencias sobre el proceso de Frobnitz para que aparezcan junto al gráfico de Easter Bunny. Ooh, así que ahora necesito un método findeasterbunny. Después de que haya hecho eso, tomará el resto de los registros, eliminará cada tercera palabra e invertirá el orden del texto. Por lo tanto, también necesitaré una textreversal y un método de textreversal . Así que una clase de 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 sea una situación para la que usaría la POO ... pero realmente depende de lo que sea más fácil para mí comprender en ese momento en particular.
Si planea usar el script de forma independiente, entonces no. Sin embargo, si planea import y reutilizarlo, sí. En el segundo caso, es mejor escribir algunas clases que proporcionen la funcionalidad que se requiere y luego realizar 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 la Objectofrenia, la ilusión de ver objetos en cada pieza de código que escribimos.
La razón por la que esto 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, comienzas a verla 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, la pregunta nos tienta. ¿Es esto algo que podría colocar en mi repositorio de clase 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 de objetos me dice que algún día escribiré? ¿Puedo estructurar mi tarea actual en uno de estos patrones?
Es un hábito molesto. Con frecuencia, es mejor no tenerlo. Pero cuando descubre que cada parte del código que escribe cae de alguna manera en patrones y refactoriza / realinea esos patrones hasta que cubra la mayoría de sus necesidades, tiende a tener una sensación de satisfacción y logro.
Los problemas comienzan a aparecer cuando un programador se vuelve ilusorio (trastorno obsesivo obsesivo a los objetos) y no se da cuenta de que hay excepciones a los patrones y tratar de manipular en exceso los patrones para cubrir más casos es incorrecto. Es como la obsesión de mi infancia de tratar de cubrir un trozo de pan completamente con mantequilla o mermelada todas las mañanas que desayunaba. A veces, es mejor dejar atrás la percepción orientada a objetos y simplemente realizar la tarea a mano 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 normalmente se percibe, podríamos decir que el 80% del tiempo tiene una percepción orientada a objetos. 20% del tiempo - codifíquelo rápido y sucio.
Sumérgete en los objetos, pero al final tendrás que resistirte a consumirte.
Probablemente aún no haya hecho suficiente programación porque si lo hiciera, vería todos los patrones que había hecho y también comenzará a creer en los patrones que aún no ha aplicado. Cuando comienzas a ver tales visiones de objetofrenia, es hora de tener cuidado de no ser consumido por ellas.
Usa la herramienta correcta para el trabajo correcto. Para scripts pequeños que no requieren algoritmos y estructuras de datos complejos, es probable que no se utilicen conceptos orientados a objetos.
Usar OOP para unos pocos 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 funciones. Si este es el caso, es mejor comenzar a codificar la programación de programación de objetos (OOP) de manera que se pague a largo plazo.
Utilizo el paradigma que mejor se adapte al tema en cuestión, ya sea de procedimiento, OOP, funcional, ... el tamaño del programa no es un criterio, aunque (por un pequeño margen) un programa más grande es más probable que aproveche las ventajas de OOP - múltiples instancias de una clase, subclases y anulaciones, sobrecargas de métodos especiales, patrones de diseño OOP, etc. Cualquiera de estas oportunidades puede ocurrir perfectamente en un script pequeño, hay una probabilidad algo mayor de que ocurra en uno más grande.
Además, detesto la declaración global , por lo que si el enfoque procedimental natural lo requiera, casi siempre cambiaré a OOP, incluso si la única ventaja es la capacidad de usar un nombre calificado en lugar del nombre de barra, lo que requeriría un nombre global .
Definitivamente no hay necesidad de "esforzarse más" en general, solo pregúntese "hay una oportunidad aquí para usar (a) múltiples instancias (etc., etc.) y pronto se convertirá en una segunda naturaleza, es decir, encontrará las oportunidades. sin necesidad de recordarse conscientemente cada vez que los busque, y su programación mejorará como resultado.
como alguien que hace muchos scripts, si tiene la idea de que su código en algún momento puede ir más allá de las 250 líneas, comience a ir. Uso mucho vba y vbscript y estoy de acuerdo en que cualquier cosa por debajo de las 100 líneas suele ser bastante sencilla y tomarse el tiempo para planificar un buen diseño de OOP es solo un desperdicio.
Dicho esto, tengo un script que llega a aproximadamente 500 líneas + y mirándolo hacia atrás, porque no lo hice, oop se convirtió rápidamente en un impío desorden de espaguetis. así que ahora cualquier cosa más de 200 líneas me aseguro de tener un buen plan OOP antes de tiempo