Tengo un inicio de una aplicación web que escribí sin utilizar las características orientadas a objetos de PHP.PHP ¿Está orientado a objetos o no?
Realmente no sé si vale la pena volver 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 tiene 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 objetos como la peste 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.
No diría que es fundamental, pero si va a ir mucho más allá con la aplicación, 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.
Las tecnologías 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.
Respuesta típica: "It depends."
Tiendo a escribir la página de visualización como una página de inicio < html> a </html> scripted. Pero las cosas que suceden en esa página son objetos. Un poco como ASP de un pobre. Mientras que puede tener salida OOP-base, siempre me pareció demasiado engorroso para una tarea tan tediosa como arrojar datos a un navegador.
Por lo tanto, las reglas comerciales y el acceso a los datos eran OOP. La presentación fue guión.
Si tiene reglas comerciales que son no 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. :-)
Simplemente 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 muchos OOP, querrá comenzar de a poco y sentirlo.
Una vez que te familiarizas con 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.
EDIT:
Sólo para añadir un par de renuncias ...
yo diría que tratar de ir OO es sólo porque lo que has puede ser reutilizado mucho más fácil que si se hace procedimental derecho
También diré que OO es 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.
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 el básico, aunque tampoco es completamente OOP
Hay dos posibilidades: o bien tu aplicación es una aplicación única que solo tiene que funcionar ahora y nunca será tocada, adaptada, expandida o modified, o bien su aplicación es el comienzo de algo con lo que continuará trabajando y utilizando durante mucho tiempo.
Si es el primero, no rompa el código perfectamente utilizable. Tienes mejores cosas que hacer con tu tiempo.
Si es lo último, debe tener en cuenta un dato importante sobre PHP, que es este: 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 una fuerte necesidad 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.
Así que si va a mantener este código a lo largo del tiempo, tómese el tiempo para hacerlo bien. Eso significa: algún tipo de sistema de plantillas, sin etiquetas PHP incrustadas en HTML, archivos separados para funcionalidades separadas, y clases de clases de !
Sus cuencas de los ojos se 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 la cantidad de PHP es orientado a objetos ... PHP4 tenía algunos elementos de OOP abofeteados, PHP5 es mejor pero no está procesado en el idioma. PHP funciona en ambos sentidos, y personalmente me gusta que pueda elegir.
En mi mente, Phper thorouly podemos desechar el concepto de objeto (instancia de clase), sólo necesitamos de la matriz y el modo Clase:
todas las matrices de compatibilidad con el modo inicial de cualquier función de matriz, ya que es el método:
<?php
$array1->array_flip(this);
?>
uso ->mode() para validar el conjunto de datos mínimos, y luego cambiar el modo de clase:
<?php
$array1->mode('class1', $success);
?>
Cualquier clase de modo no tiene ->construct() en él, 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 método, pero después de usar cualquiera de ellas la matriz volverá al modo de matriz básica, y necesitamos usar ->mode('class1', $success); para volver al modo de conmutación.
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 la clase de modo, podríamos llamarlo MyPHP.
Por ejemplo: $array_man1 podría fijarse 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();
?>
En realidad estoy tratando de pensar en maneras de promover un mejor código PHP, pero es una tarea de enormes proporciones. . . –