Como hay para casi todo un módulo y se dice repetidamente que no debemos reinventar la rueda y dado que no escribo módulos para CPAN, no necesito usar OO. Pero mi pregunta es, ¿el código profesional de Perl está escrito principalmente en estilo OO?¿El código de Perl está escrito principalmente en diseño orientado a objetos?
En resumen, solo si desea la reutilización y legibilidad del código; para escribir scripts o código de sistema simple para realizar una tarea, entonces es un desperdicio, especialmente si es el tipo de cosa que no va a estar bien documentada. Al escribir un programa complejo, por ejemplo, realmente ayuda a organizar los pensamientos y modularizar el problema escribiendo una serie de, bueno, módulos. Los beneficios de usar orientación a objetos aumentan exponencialmente cuando se trabaja en un proyecto con más de un desarrollador.
¿Cuál es la implicación de reutilización de código y legibilidad con estilo OO? El estilo OO es para abstracción de datos y para modelado. No resuelve la legibilidad o la reutilización. Se trata de arquitectura y diseño. He visto muchos códigos de estilo de OO incorrectos que no se pueden leer ni volver a utilizar. Usar OO para abstracción de datos y modelado y estilo funcional para funciones es la mejor recomendación para mí. El estilo OO es necesario para los lenguajes expresivos malos como C, Java, C#. No es el caso de Perl. –
@Hynek -Pichi- Vychodil: creo que se puede argumentar que la compartimentación del código proporcionado por las técnicas de OO es otra herramienta para hacer que el código sea más expresivo, lo que aumenta la legibilidad, la capacidad de mantenimiento y la reutilización. Si la expresividad conduce a esos atributos en las manos correctas, y las técnicas OO proporcionan expresividad, entonces las técnicas OO pueden proporcionar esos atributos si se usan correctamente. En caso de que aún no haya golpeado a todos en la cabeza con suficiente, esto depende, por supuesto, del programador. – kbenson
La mayor parte del código de Perl que escribo es de tamaño pequeño y nunca uso OOP para ellos, incluso si usan módulos de CPAN que están diseñados por OOP. Para los proyectos de código más grandes, tiendo a OOP aproximadamente el 70% de las veces pero depende: ¿se va a usar el código durante mucho tiempo? Si es probable que permanezca y muchos usuarios sumerjan sus cucharas en la mezcla, OOP probablemente sea un mejor diseño.
OO-Design no es una "bala de plata". No hay daño al escribir código que no es-OO. Es solo la opción "popular". Como dijo alguien una vez (y parafraseo):
OO-design simply had a better marketing group
Esto es sólo Partiendo del hecho de que la gente cree "la mayoría del código" debe ser OO. Por supuesto, puede hacer un seguimiento del estado "internamente en un objeto", pero también hará que la gente haga cosas tontas dentro del objeto que hacen las cosas más complicadas también.
Mi problema es con "most code written in OO". Creo que debería haber un equilibrio saludable entre Objetos y Funciones. Las funciones pueden operar en Objetos.
Hay muchas cosas que no se prestan muy bien a los objetos.
No estaría de acuerdo; OOP no es solo un estilo diferente, es un paradigma fundamentalmente diferente. Para arquitecturas complejas puede hacer una diferencia * sustancial * en la organización y mantenimiento del código. –
Sí, el diseño OO no es una bala de plata, pero decir que solo tiene un mejor grupo de marketing significa que se está perdiendo. Algunos problemas se prestan naturalmente a las soluciones OO. Otros a soluciones funcionales. Es por eso que Perl es tan amable porque puedes hacer una o ambas cosas según la situación lo requiera. – mpeters
Si está escribiendo un script simple para hacer un proceso relativamente simple, modificación de archivos, etc. está bien ir con un diseño que no sea OO, pero en mi experiencia si el script durará más tiempo y potencialmente puede hacer cosas es posible que algún día desee reutilizarlo en otro guión o en un contexto diferente al que planificó para su mejor uso con el enfoque OO. En general, también es mucho más fácil escalar y mejorar un diseño basado en OO.
Especialmente cuando se trata de la representación de datos de cualquier tipo. Una vez que haya escrito una clase para representar esos datos, es muy conveniente agregar métodos útiles a esa clase de datos (como mostrar, verificar, analizar, restablecer, escribir en un archivo, cargar desde un archivo, etc.).
Esto también tiene un efecto secundario positivo de hacer que sus scripts sean mucho menos detallados y fáciles de leer y mantener ya que muchos de los detalles de operación en los datos se dejan a los métodos de la clase. Si está tratando con grandes conjuntos de datos, también es mucho más fácil tratar con matrices de objetos que con hashes, que probablemente terminará usando mucho si no tiene un diseño OO.
En el futuro, si tiene que escribir un script para procesar los mismos datos de una manera diferente, puede simplemente reutilizar las clases de datos en un script diferente. Si los datos son un poco diferentes, debe agregar más campos o más métodos. no hay problema simplemente extender la clase de datos original.
La mejor referencia para aprender OO Perl que he encontrado es: Perl orientado a objetos: una completa guía de conceptos y técnicas de programación de Damian Conway.Una de las cosas con las que luché cuando comencé a hacer OO Perl es que hay muchas maneras diferentes de hacerlo. Finalmente, me decidí por uno y me he quedado con él a lo largo de los años.
Veo OOP principalmente como una forma de vincular y establecer comportamientos a una estructura de datos. Cada vez que parezca que mis estructuras de datos se van a complicar, compongo objetos.
Esto ayuda a centralizar y abstraer el código relacionado con la manipulación de los datos. Que a su vez reduce el código duplicado y simplifica la refactorización. Lo mismo podría lograrse utilizando un código puramente de procedimiento. Encuentro que OOP hace que la relación sea explícita y más fácil de conceptualizar de una manera intuitiva.
considerar esta estructura:
my $foo = {
meezle => [qw(a d g e l z)],
twill => {
prat => 'qua',
nolk => 'roo',
},
chaw => 7,
mubb => [ 123, 423,756, 432 ],
ertet => 'geflet',
};
Cuando termino con una estructura como esta (no uniforme y anidada), me pongo a pensar "objeto". Me aseguro cuando me encuentro escribiendo mucho código para acceder, modificar y validar datos en la estructura.
Dado que la mayoría de los proyectos no triviales requieren manipulaciones de datos no triviales, uso objetos para al menos una parte de la mayoría de los trabajos.
Puedo o no ir a por todas en mi OOP. Por lo general, hay algunas cosas que no son objetos. Puede haber o no una clase base de aplicación. Algunos elementos pueden manejarse como un código de procedimiento normal. Algunos pueden incluir enfoques funcionales. Todo depende de lo que tenga sentido dados los requisitos del proyecto.
Lo más importante que debe recordar es que su código debe ser claro para el pobre idiota encargado de mantenerlo. (Podría ser usted en 6 meses, recién despertado de un sueño profundo de 4am, con el jefe del jefe de su jefe gritándole que arregle el maldito software antes de que la empresa se arruine.)
Creo que "profesional" es muy subjetivo aquí . Quizás usar términos como pequeños y grandes con ejemplos para definir cada uno en este contexto tendría más sentido. – kbenson
Recuerde elegir la mejor respuesta. – amphetamachine