Tuve la oportunidad de tener una conversación interesante con mis compañeros de trabajo. La mayoría de ellos son scripts de acción flash o desarrolladores de Java.
Hablamos de lo bien que php maneja OOP. Dije que PHP puede manejar casi todas las cosas OOP desde PHP 5.2 o 5.3. ¿Me equivoco? No estoy tratando de obtener una respuesta de sí / no, pero me gustaría escuchar más opiniones de los desarrolladores.
PHP 5.3 en realidad tiene un soporte bastante decente para OOP.
El problema con PHP con respecto a la POO es que la POO realmente se integró al lenguaje, mientras que en lenguajes como Java y ActionScript es parte del concepto central, aunque considero que ambos lenguajes POP son malos debido a sus pobres Semántica de objetos.
A pesar de que PHP en la actualidad es muy adecuado para OOP, el problema es que:
array sigue siendo el tipo más importante y más utilizado y no es un objeto. PHP no puede simplemente deshacerse de todas las cosas heredadas. Si se lanzara un PHP 6, eso arroja la mayor parte, probablemente no se usaría. Derrotaría su propósito.
Y PHP no pudo tomar un ritmo suficiente de desaprobación gradual de las cosas. Por lo tanto, tomará un tiempo hasta que obtenga la claridad y la consistencia necesarias que debe tener un buen lenguaje.
Personalmente, realmente no me gusta PHP, simplemente por todo ese equipaje, la API y todo.
Sin embargo, marcos como Flow3, Symfony, CakePHP y Codeigniter proporcionan una base sólida para OOP y otros paradigmas poderosos. Debido a la restricción de ActionScript y Java, con suficiente esfuerzo (una capa de abstracción sobre fallas de PHP), PHP puede estar a la par o incluso superarlos.
Para resumir: no hay nada particularmente malo con las instalaciones OOP de PHP. Por lo tanto, se podría decir que no es un mal lenguaje OO . Sin embargo, hay muchas cosas particularmente malas con PHP, como las instalaciones OOP que realmente no están integradas , sino simplemente incluidas , por lo que podría argumentar que es malo OO idioma.
Encontrarás que " puede manejar " no es lo mismo que " admite ". Me refiero a que, en las pocas cosas, incluso C " puede manejar " OOP si estructuras tu código correctamente. La pregunta es si el lenguaje va o no más allá de simplemente habilitar OOP para alentarlo haciendo que la POO sea la forma más natural de programar.
En mi (experiencia limitada) los dialectos de PHP 5.n no hacen esto. Es demasiado fácil deslizarse fuera de la programación orientada a objetos y pasar a un código de procedimiento bastante puro. (Tenga en cuenta que no creo que PHP sea un mal lenguaje por esta razón. Hay muchas razones por las que creo que PHP es un mal lenguaje, pero la compatibilidad con OOP no es una de ellas.
En realidad, hay dos definiciones de la orientación a objetos de un lenguaje: la orientación a objetos es su propia sintaxis y bibliotecas estándar integradas, y la influencia que tiene en los programadores de software que escriben para ello.
Por la primera definición, PHP parece estar al final de la lista. La gente a menudo cita cadenas y matrices sin objeto como evidencia de esto. En mi opinión, esta definición realmente no importa. Siempre puede envolverlo en un objeto si realmente necesita uno, pero la gente no lo hace porque no lo hacen. Por lo general, la única diferencia que hará al código es cambiar function(var) a var.function() . La sintaxis por sí sola no cambia algo de no-OOP a OOP.
En cuanto a la segunda definición, las personas logran escribir código orientado a objetos pobremente, incluso en lenguajes que imponen tales construcciones, y las personas que escriben código orientado a objetos correctos apenas se ven afectadas por el lenguaje, excepto por las molestias sintácticas. En otras palabras, en mi experiencia, no hay lenguajes mal orientados a objetos, solo programadores mal orientados a objetos. PHP es tan bueno como cualquier otro idioma en ese sentido.
Tal vez algunos lenguajes son más adecuados para aprender la programación orientada a objetos, pero creo que el desarrollador diferirá. Para mí, no hizo clic hasta que leí el libro de camellos de Larry Wall sobre cómo hace Perl (¿lo hizo?) OOP. Tener que bendecir explícitamente las referencias, ya que pertenecer a una clase, realmente me llevó a entender el problema de lo que realmente es una instancia de un objeto frente a lo que es una clase. Algunas personas prefieren el enfoque de aprendizaje de todos los objetos y todo el tiempo de Java. Dado que la OOP es más una preocupación arquitectónica, es más fácil de aprender después de conocer las variables básicas, las expresiones, la secuencia, la selección y la iteración, por lo que cualquier idioma que no te ofrezca OOP de inmediato tiene una ventaja educativa en mi opinión.
Cuando mi esposa hizo una introducción a la clase de programación con java, se sintió frustrada constantemente por el public static void main y puso todo en una clase, que aún no tenía el fondo para entender, pero su maestra se lo dijo confiar en que ella lo necesitaba. Traté de explicarlo, pero es muy difícil explicárselo a alguien que apenas supo sobre las variables por qué sería útil evitar que otras partes del código accedan a ellas y cómo decidir cómo dividirlas. Podría argumentar que el aprendizaje de la programación de procedimientos primero inculca malos hábitos, pero ¿qué pasa con el hábito de copiar y pegar códigos que no entiende?
PHP no es malo para la programación orientada a objetos. Sin embargo, la naturaleza de PHP alienta a los trucos y arreglos rápidos en comparación con el desarrollo adecuado de software orientado a objetos, y muchos libros y tutoriales ignoran por completo los conceptos OOP. Puede admitir conceptos de POO muy bien, pero es responsabilidad del desarrollador saber cómo aplicarlos. Puede hacer casi cualquier cosa en PHP que pueda hacer en un lenguaje "verdadero" OOP como Java o C #, pero esos lenguajes tienen más aplicación de las técnicas de OOP que PHP, que podrían usarse con un estilo de procedimiento si lo desea.
No puedo recordar la cita exacta, pero fue de alguien que comparó PHP en bruto con el uso del nuevo Ruby on Rails, y fue algo como esto: Rails hace que escribir un buen código sea fácil y que escribir un código malo sea difícil . PHP facilita la escritura de código incorrecto y dificulta la escritura de código bueno. La línea sobre PHP prácticamente lo resume en OOP; es perfectamente capaz de ser un buen lenguaje OO, pero hace que sea un poco más difícil hacerlo.
PHP es solo un lenguaje de pegado al igual que BASH o Perl. Es bueno en eso, pero no es bueno en nada más, deja de lado algún trabajo serio. El lenguaje no está diseñado. Simplemente se desarrolla mediante la piratería de varios códigos de forma aleatoria (código y corrección).
A diferencia de PHP, Java es un lenguaje compilado que ha sido diseñado adecuadamente. Existen JSR que definen el lenguaje, muchos marcos y conceptos de nivel empresarial como EJB, JMS, ESB, Spring, Struts, Hibernate y otros.
En términos de sistemas empresariales, Java EE es una solución que se ajusta al propósito (Enterprise Edition), mientras que PHP se usa en compañías que intentan reducir los costos al contratar mano de obra barata con menos calificaciones.
Se ha realizado un esfuerzo considerable para arrastrar PHP en el segmento de la empresa utilizando varios marcos. En particular, Zend Framework 2 . El problema fundamental aquí no es la orientación a objetos de PHP, sino la falta de diseño, falta de tipificación sólida, soluciones no estándar para problemas estándar (tipo de pirateo para todo) y una falta completa de cualquier arquitectura prescrita.
Con PHP, la carga del software de arquitectura aún depende de los desarrolladores que han estado haciendo un trabajo muy deficiente, es decir, a menudo no tienen ninguna arquitectura, solo codifican y arreglan al azar. La seguridad y las transacciones faltan y deben ser calzadas por los desarrolladores. En Java, se anota una solución EJB. También considere el hecho de que, en PHP, no ocurre nada si omite las excepciones de captura o comete varios errores. Eso es hasta el tiempo de ejecución. Con Java, recibirá advertencias y errores directamente en el momento del diseño. Eso se llama robustez, pero con PHP solo puedes seguir soñando.
PHP no admite subprocesos múltiples. El código es siempre un solo hilo. Esto dificulta su rendimiento para problemas no triviales bajo una carga más pesada. Con Java EE, el multihilo es totalmente compatible, por ejemplo, a través de la interfaz Runnable.
También considere la implementación, los servicios web y otros estándares. Mientras que en Java, hay grandes empresas como Oracle, IBM, RedHat, Apache y muchas otras, PHP solo tiene Zend.
Para concluir, PHP es un lenguaje muy mal orientado a objetos. Estrictamente hablando, ni siquiera está orientado a objetos, sino híbrido, lo que es malo en las versiones > 5 porque la OOP se mezcla con la programación de procedimientos. Solo recomendaría PHP como pegamento como BASH, pero para trabajos serios usaría Java EE.
El acuerdo principal con el último Zend Framework 2 es que está intentando ser como Java EE, pero falla completamente al entregar por lo menos un conjunto de paquetes, características, herramientas, automatización, comprobación de errores, arquitectura, remotamente comparables. Diseño, y todo.
En mi experiencia, es más caro usar PHP para proyectos complejos que con Java.
También hay algunos rumores como que PHP significa Programación Bastante Horrible . Puedo confirmar estos.
¿Qué tan bien un idioma maneja la POO? Preferiría preguntar qué tan bien puedo escribir un programa de forma OO. Puedo echarle una ojeada a la postura de todo lo que debería ser una clase adoptada por Java al hacer que todo sea público estático .
PHP soporta OOP; no me obliga a escribir en modo OO solamente. La forma en que lo maneja depende de lo bien que entiendo y escribo el programa de forma orientada a objetos.
PHP admite Traits! (a partir de 5.4) . Cualquier idioma que pueda manejar la reutilización horizontal de forma nativa es un lenguaje OO lo suficientemente bueno en mi libro.
Bueno, tenemos que pensar en qué es lo que hace que un lenguaje sea más OO y qué razones hay para hacerlo así.
JavaScript es una implementación de ECMAScript que pretende ejecutarse en el entorno del navegador como un lenguaje interpretado . El hecho de que se piense que es un lenguaje interpretado tuvo un gran efecto en su diseño sintáctico / conductual.
Por ejemplo, no sigue OOP. Pero aparte de eso, hay muchos datos como, por ejemplo, el programador OO puede encontrar algo de su comportamiento como elevación de funciones muy confuso.
Una vez más, hay muchas cosas que vienen con lenguajes OO como C ++, Java, C # para que sean más eficientes para el compilador como escritura fuerte . Sin embargo, dado que JS se ejecuta en un entorno interpretado, no sigue una tipificación fuerte, sino que es un lenguaje tipificado de forma flexible .
Aparte de las diferencias de comportamiento anteriores, hay muchas diferencias sintácticas, ya que JS tiene Notación literal de objetos que pueden confundir a los programadores de C #. Sin embargo, C # también tiene una sintaxis literal de Objeto, aunque es un lenguaje compilado y esa sintaxis rara vez se usa ya que tradicionalmente no es un estilo de código OO.
Ahora hay un punto más que determina si el lenguaje es bueno OO: es que evolucionó desde C ++. A medida que Java, C # evolucionan desde C ++ y siguen un comportamiento y sintaxis similares, una gran comunidad percibe dicho comportamiento y sintaxis como la única cosa OO , y piensa que cualquier lenguaje que no inhiba tales similitudes es simplemente No también.
Sin embargo, no olvidemos que OO es un concepto muy abstracto, no está vinculado a ningún estilo de sintaxis e incluso no a ninguna propiedad específica de comportamiento.
Y PHP está muy bien OO. Simplemente no pareciendo y sintiendo como Java, C ++, C # no hace que sea un lenguaje pobre de OO. Bueno aprendí C ++, luego Java y luego C #.
Entonces, hasta ahora mi cabeza estaba muy bien OO. Luego aprendí JS de un muy buen libro "Wrox Pro", y simplemente me exageró. Acabo de disfrutar del comportamiento y la distinción sintáctica de JS. Entonces me doy cuenta de que la sintaxis literal de los objetos estaba en su C #. Y ahora, mientras estoy aprendiendo PHP, siento que trae muchas cosas de ambos mundos.
Todo lo que tenemos que hacer es aprender la sintaxis y las sutilezas de comportamiento que tiene un lenguaje al implementar OO. Una vez que los dominemos, podemos comenzar a pensar que esta es una mejor implementación de OO.
Lea otras preguntas en las etiquetas object-oriented php