programacion - php ya orientado a objetos
PHP ¿Está orientado a objetos o no? (10)
Tengo un inicio de una aplicación web que escribí sin utilizar las características orientadas a objetos de PHP.
Realmente no sé si vale la pena regresar y volver a escribir las partes que he terminado. ¿El PHP orientado a objetos vale la pena reescribir todo o parte de una aplicación de trabajo decente?
Dado que tienes una aplicación incompleta, diría que volver a trabajarla en una aplicación basada en Objetos probablemente sea útil.
Una cosa a considerar es el tamaño esperado de la aplicación final. Debajo de cierta complejidad, la base de Objetos puede ser excesiva, excepto por la experiencia de aprendizaje.
Empecé evitando Objects like the plague porque mi introducción inicial a ellos en las clases universitarias fue terrible. Recientemente tuve que trabajar en un proyecto que se implementó en php objects. hacer los cambios requeridos fue mucho más fácil que otros proyectos. Desde entonces, he trabajado en el modelo de objetos con frecuencia y me resulta muy útil para una creación rápida y un mantenimiento más fácil.
Las técnicas orientadas a objetos de aprendizaje serán realmente útiles, especialmente para la programación en otros idiomas en el futuro.
Como acaba de iniciar la aplicación, puede volver a escribir y mejorar las partes que ha escrito. Depende de tu fecha límite.
No diría que es crítico, pero si vas a ir mucho más allá con la aplicación, te recomendaría hacerlo ahora, aunque no es una tarea tan monumental. Yo diría que la mantenibilidad de un programa OOP bien escrito podría superar los costos iniciales. Especialmente cuando considera que podrá refactorizar gran parte del código a medida que avanza.
Respuesta típica: "Depende".
Tiendo a escribir la página de visualización como una página con guión de inicio a fin, <html> a </ html>. Pero las cosas que suceden en esa página son objetos. Un poco como ASP de un pobre. Si bien puede tener salida basada en OOP, siempre pensé que era demasiado engorroso para una tarea tan tediosa como arrojar datos a un navegador.
Entonces, las reglas comerciales y el acceso a los datos eran OOP. La presentación fue guión.
Si tiene reglas comerciales que no son OOP, consideraría seriamente escribirlas como objetos en dos condiciones: (1) es "¿Tiene tiempo / esfuerzo / dinero para hacerlo?" y (2) es "¿Tiene un buen PHP IDE que le hará la vida más fácil?" Si funciona, y cambiarlo significa escribir en Notepad ++, entonces lo llamaría hecho. :-)
Solo para estar en desacuerdo con el consenso ... Diría que no en la mayoría de los casos. No como un ejercicio académico en el código comercial de todos modos. Si funciona, no lo vuelva a escribir. Si tiene que entrar para cambiar / agregar bits, vuelva a configurar las prácticas de OO (hay muchas publicaciones en SO sobre la refactorización cuando se cambia el código de todos modos, y no solo por el hecho de hacerlo).
En la práctica, si no ha hecho mucho OOP, querrá empezar de a poco y sentirlo.
Una vez que conozca los conceptos básicos, una buena guía para principiantes sobre Patrones de diseño (Me gusta el libro de Head First) es muy útil. La mayoría de los libros de PHP le enseñarían OOP bastante mal. Te enseñan acerca de la herencia, pero generalmente no te enseñan sobre el acoplamiento flexible y favorecen la composición sobre la herencia. Un libro de patrones de diseño le dará una mejor idea de esto.
PHP todavía tiene una reputación de no "hacer" OO bien. No creo que esto sea justo, pero es un reflejo del hecho de que es tan fácil para las personas comenzar sin tener realmente OOP. Me gustaría salir de una extremidad y decir que la mayoría (muy ligeramente - llámalo el 51%) de los programadores de PHP no se sienten cómodos con OOP. Creo que es posible hacer un buen OO en PHP, y si ya te sientes cómodo con el idioma, es una excelente forma de desarrollar tus habilidades.
EDITAR:
Solo para agregar un par de renuncias ...
- ¡Mi comentario acerca de que la mayoría de los programadores de PHP no estén cómodos con OOP no se aplicaría a la audiencia SO actual!
- No sugiriendo que no se sienta cómodo con OOP, esto aplica si no está
Yo diría que intente y se vaya solo porque lo que tiene se puede reutilizar mucho más fácil que lo que se debe hacer en caso de que se haga bien.
También diré que OO está mucho más organizado que de procedimiento. Cuando se trata de una escala pequeña, es fácil salirse con la suya con un código descuidado OO o no. Pero cuando se llega a proyectos más grandes, su procedimiento debe estar mucho más organizado y pensado. Mientras que en algunos proyectos más grandes, OO tiende a forzarte a estar más organizado, facilitando las cosas un poco.
Hay dos posibilidades: o bien su aplicación es una aplicación única que simplemente tiene que funcionar en este momento y nunca será tocada, adaptada, expandida o modificada, de lo contrario, su aplicación es el comienzo de algo con lo que usted seguirá trabajando y utilizando mucho tiempo.
Si el primero, no rompa el código perfectamente utilizable. Tienes mejores cosas que hacer con tu tiempo.
Si esto último, debes tener en cuenta un hecho importante sobre PHP, que es el siguiente: PHP mal escrito es una pesadilla para mantener. No es tan malo como Perl mal escrito, porque ¿qué es? - pero lo suficientemente malo como para que tarde o temprano sienta un fuerte impulso de robar una máquina del tiempo, regrese al momento en que escribió el código que ahora se encuentra manteniendo, y apuñale en la cuenca del ojo con un picahielo.
Entonces, si va a mantener este código a lo largo del tiempo, tómese el tiempo para hacerlo bien. Esto significa: ¡algún tipo de sistema de plantillas, sin etiquetas PHP incrustadas en HTML, archivos separados para funcionalidades separadas y clases de clases !
Tus cuencas de los ojos te lo agradecerán.
Me gustaría reiterar las otras respuestas aquí. Depende del tamaño de la aplicación y de cuánto le gustaría aprender sobre OOP. Sin embargo, tendría cuidado de aprender OOP usando PHP.
En cuanto a cuánto PHP está orientado a objetos ... PHP4 tenía algunos elementos OOP abofeteados, PHP5 es mejor pero no está procesado en el lenguaje. PHP funciona en ambos sentidos, y personalmente me gusta que pueda elegir.
No, creo que si la aplicación funciona como debería, no hay necesidad de volver a escribirla. PHP no es realmente POO en absoluto. Se esfuerzan, pero a veces creo que incluso los desarrolladores de PHP realmente no entienden el sentido de OOP. Si desea aprender OOP (que seguramente es una buena idea) intente con un lenguaje OOP real como Smalltalk para aprender los conceptos básicos. Java también es bueno 2 aprende lo básico, aunque tampoco es completamente OOP
En mi opinión, phper puede descartar por completo el concepto de Object (instancia de clase), solo necesitamos Array y Mode Class:
Todas las matrices en modo inicial admiten cualquier función de matriz como método:
<?php
$array1->array_flip(this);
?>
Use ->mode() para validar el conjunto de datos mínimo, y luego cambie la clase de modo:
<?php
$array1->mode(''class1'', $success);
?>
Cualquier clase de modo no tiene ->construct() en ella, pero tiene ->validate() para validar el conjunto de datos mínimo.
La matriz en un modo todavía podría usar la función de matriz como su método, pero después de usar cualquiera de ellos la matriz volverá al modo de matriz básica, y necesitamos usar ->mode(''class1'', $success); para regresar el modo.
El pensamiento radical es la programación centrada en datos, necesitamos separar los datos (matriz) y la actividad (método de clase).
Podríamos modificar el motor de PHP, deshacernos de partes de OO (orientado a objetos) y admitir Mode Class, podríamos llamarlo MyPHP.
Por ejemplo: $array_man1 podría configurarse en dos modos: cls_normal_man y cls_crazy_man :
<?php
$array_man1->mode(''cls_normal_man'')->normal_method1()->mode(''cls_crazy_man'')->crazy_method1();
?>