Código de procedimiento vs código OOP

Terminé un proyecto en PHP de más de 13000 líneas en estilo de procedimiento [porque estoy muy familiarizado con eso, aunque conozco POO], y el proyecto se ejecuta perfectamente.

¿Pero debería convertirlo a OOP? [ porque el mundo está ocupado con OOP ]

¡Mi código no necesita ninguna de las características de OOP [encapsulación, herencia básicamente ...]!

¿Entonces qué debo hacer?

¿Y qué tipo de ayuda obtendré si la convierto a OOP?

Mi código no necesita ninguna de las características de OOP

Ha respondido su propia pregunta: si no necesita OOP en este caso y su proyecto está funcionando, no lo convierta.

Sin embargo, debe considerar el uso de OOP para su próximo proyecto, pero solo si es apropiado.

No hay nada intrínsecamente malo en la programación de procedimientos, siempre y cuando se use en el lugar apropiado.

No y no solo porque no necesitas OOP.

Si su programa ya ha terminado y funciona satisfactoriamente, más del 90% del tiempo es una pérdida de tiempo volver a escribir el código terminado por cualquier razón.

OOP no es todo poderoso, hay muchos lugares donde OOP no debe usarse, así que no lo use solo porque OOP es la tendencia.

Mi opinión general sobre los paradigmas (y por qué ninguno de los tres paradigmas principales es la forma correcta o incorrecta de programar):

La programación de procedimientos es buena cuando tiene un problema que es simple en un nivel alto (aunque puede ser complejo en un nivel bajo) y desea escribir un código lineal correspondientemente simple. Podría decirse que es más fácil de escribir y comprender que OO y funcional si el problema no necesita un desacoplamiento fuerte en alguna parte. Ejemplos: código numérico, la mayoría de los scrips pequeños, la mayoría de los subproblemas pequeños una vez que haya desglosado las cosas usando OO o funcional.

El código orientado a objetos es bueno cuando necesita desacoplar fuertemente las preocupaciones porque puede tener más de una implementación de algunas preocupaciones. Ejemplo: la mayoría del software para grandes empresas. Es posible que, por ejemplo, desee desacoplar fuertemente la lógica de negocios de la lógica de presentación porque probablemente tendrán que cambiar de forma independiente.

La programación de estilo funcional es buena cuando necesita una fuerte separación del mecanismo de la política. Tener una función de mecanismo que acepte una función de política es un buen patrón. (Lo aprendí mirando el módulo std.algorithm del lenguaje de programación D ). Abstraer el estado mutable en el límite entre el código de política y mecanismo generalmente hace que la API sea más fácil de razonar. Si el estado mutable se usa de forma privada en cualquiera de los dos, este es un detalle de implementación. La otra fortaleza de la programación funcional es la concurrencia, por razones evidentes.

El código nunca "necesita OOP". Son los programadores, en la medida en que son capaces de pensar en diferentes modos, quienes imaginan que este o aquel problema particular "necesita" $ PARADIGM o se resuelve mejor de esa manera.

A menudo, los programadores que solo conocen un paradigma piensan que su paradigma es el más grande. Una talla para todos, y todos debemos dormir en la cama de Procrustes, si esto o aquello está de moda actualmente.

Solo debe convertir su proyecto a OOP si hay una clara indicación de la necesidad de OOP. Los posibles escenarios en los que esto puede ocurrir son (entre otros):

• ampliando el proyecto
• agregando más desarrolladores al equipo

e incluso en estos escenarios, puede que aún no sea necesario convertir su proyecto a OOP.

Ambos pueden ser buenos, ambos pueden ser malos. Pero adaptar una para que se parezca a la otra nunca es una buena idea.

Si recuerdas por qué se inventó la OO, verás que no necesitas OOP en absoluto, pero a veces te hace la vida mucho más fácil.

En los días de la codificación C, un programa muy grande podría volverse bastante complicado y difícil de seguir trabajando. Entonces inventaron formas de dividirlo en trozos modulares. OOP adopta este enfoque y lo hace aún más modular, colocando datos con esos fragmentos de lógica de programa para que estén aún más separados del resto del código.

Esto le permite escribir programas cada vez más grandes, con la seguridad de que ha cambiado su enorme elefante de tarea en cien tareas del tamaño de un ratón. ¡La ventaja adicional es que puedes tomar algunos de estos 'ratones' y reutilizarlos en otros programas!

Por supuesto, el mundo real no es así, y la reutilización de objetos nunca se dio cuenta de la forma en que se pretendía, pero eso no significa que sea un paradigma inútil.

Lo que es inútil es una excesiva dependencia de cualquiera de los estilos de codificación. Cualquiera que haga OO con mil clases pequeñas e insignificantes no lo está haciendo bien, está haciendo una pesadilla de mantenimiento para sí mismo (o para otra persona). Cualquiera que escriba una aplicación de procedimiento que tenga solo 3 funciones también está dificultando la vida. La mejor manera es la tierra media, objetos de gran tamaño (a veces llamados componentes que es donde buscamos estar alguna vez) que pueden proporcionar una buena cantidad de código independiente y datos que es mucho más probable que se reutilicen de forma aislada del resto de tu aplicación.

Mi consejo para la próxima vez: intente escribir su código de procedimiento habitual, pero cree un solo objeto de su estructura de datos principal. Vea cómo le resulta más fácil trabajar con él que pasar datos de una función a otra.

¡Mi código no necesita ninguna de las características de OOP [encapsulación, herencia básicamente ...]!

¿Como sabes eso?

¿Necesitas mantener este proyecto? ¿Hay nuevas características planificadas? ¿Habrá otras personas que se desarrollarán contigo? ¿Te repitiste a ti mismo? ¿Es difícil de entender el código?

Si la respuesta es "sí", entonces tal vez debería comenzar a pensar en configurar un esqueleto OOP y seguir este camino.