¿Por qué usar PHP OOP sobre funciones básicas y cuándo?

Question

Hay algunas publicaciones sobre este tema, pero no entendí claramente cuándo utilizar la codificación orientada a objetos y cuándo usar las funciones programáticas en una inclusión. Alguien también me mencionó que OOP es muy pesado para ejecutar, y hace más trabajo. ¿Es esto correcto?

Digamos que tengo un archivo grande con 50 funciones. ¿Por qué querré llamar a estos en una clase? Y no por function_name()? ¿Debería cambiar y crear un objeto que contenga todas mis funciones? ¿Cuál será la ventaja o la diferencia específica? ¿Qué beneficios trae para codificar OOP en PHP? ¿Modularidad?

Answer 1

En muchos escenarios, la programación de procedimientos está bien.Usar OO por el solo hecho de usarlo es inútil, especialmente si va a terminar con objetos POD (plain-old-data).

El poder de OO proviene principalmente de la herencia y el polimorfismo. Si usa clases, pero nunca usa ninguno de esos dos conceptos, probablemente no necesite utilizar una clase en primer lugar.

Uno de los mejores lugares IMO que OO brilla, le permite deshacerse del código de encendido. Considere:

function drive($the_car){ 

    switch($the_car){ 

     case 'ferrari': 
      $all_cars->run_ferrari_code(); 
      break; 

     case 'mazerati': 
      $all_cars->run_mazerati_code(); 
      break; 

     case 'bentley': 
      $all_cars->run_bentley_code(); 
      break; 
    } 
} 

con su alternativa OO:

function drive($the_car){ 

    $the_car->drive(); 
} 

polimorfismo permitirá que el tipo apropiado de "conducir" a suceder, basándose en la información de tiempo de ejecución.

---

Notas sobre el polimorfismo:

El segundo ejemplo que aquí tiene algunas premisas: Es decir que todas las clases de coches o bien se extenderá una clase abstract o implementar un interface.

Ambos le permiten forzar la extensión o implementar clases para definir una función específica, como drive(). Esto es muy poderoso ya que le permite a drive() todos los automóviles sin tener que saber a cuál conduce; eso es porque están ampliando una clase abstracta que contiene el método drive() o implementando una interfaz forzando el método drive() para ser definido.

Por lo tanto, siempre y cuando se asegure de que todos sus coches específicos o bien extender la clase abstracta car o implementan una interfaz como canBeDriven (ambos de los cuales debe declarar el método drive()) sólo se puede llamar al método drive() en una objeto que usted sabe que es un automóvil (pero no qué tipo de automóvil) sin temor a que se defina, ya que PHP le arrojará errores fatales hasta que usted defina esos métodos en sus clases específicas de automóvil.

Answer 2

Si tiene 50 funciones en lugar de 50 métodos estáticos en la clase Utilidades, "contaminará" el espacio de nombres global.

Utilizando una clase con 50 métodos estáticos, los nombres de métodos son locales para su clase.

Answer 3

El uso de un enfoque de programación orientado a objetos en lugar de un enfoque de programación de procedimientos en un programa realmente no depende del lenguaje (ya sea PHP o no), sino del tipo de problema que está tratando de resolver.

(sólo voy a usar pseudocódigo en mis ejemplos ya que no estoy muy familiarizado con PHP.)

Por ejemplo, si tiene un programa en el que apenas está llevando a cabo un montón de funciones con el fin, entonces el procedimiento va a estar bien. Por ejemplo, si se trata de un simple programa de manipulación de cadenas, un enfoque de procedimiento sería suficiente:

perform_truncation(my_string, 10) 
to_upper(my_string) 
perform_magic(my_string, hat, rabbit) 

Sin embargo, si se va a tratar con muchos elementos diferentes (tales como archivos, o cualquier otra representación de, bueno, objetos) entonces un enfoque orientado a objetos sería mejor.

Por ejemplo, si usted tenía un montón de Car s y les deseó drive, a continuación, en el procedimiento, es posible hacer algo a lo largo de la línea de:

drive_car(first_car) 
drive_car(second_car) 

Donde como, en programación orientada a objetos, la Car lata conducir a sí mismo:

RedCar myRedCar(); 
BlueCar myBlueCar(); 

myRedCar.drive(); 
myBlueCar.drive(); 

Y, como cada automóvil es una clase diferente, su comportamiento se puede definir de manera diferente. Además, pueden ser ambas subclases o Car que pueden tener una funcionalidad común.

Realmente se reduce al tipo de problema que hace que cualquier enfoque de procedimiento sea mejor que orientado a objetos y viceversa.

Aparte del problema de los procedimientos u orientados a objetos, puede ser una especie de "olor a código" tener un archivo fuente con muchas funciones. Esto también se puede decir acerca de las clases que contienen muchas funcionalidades que se pueden realizar mejor como funciones separadas en clases separadas.

El problema aquí puede ser la organización del código en lugar de decidir elegir la programación de procedimiento u orientada a objetos. Organizar las funciones en archivos fuente separados puede ser lo que se necesita aquí que abandonar el enfoque de procedimiento para escribir el programa.

Después de todo, hay muchos programas escritos en el enfoque de programación de procedimientos que están bien escritos y son fáciles de mantener.

Answer 4

No puedo decir cuál es mejor. pero en mi experiencia puede tener una mejor administración de código usando OOP. usted sabe qué código es dónde, qué funcionalidad se define en qué archivo, etc. sobre la sobrecarga de tiempo de ejecución para OOP que leí en alguna parte (y creo que es cierto) que si escribe un código incorrecto en funciones clásicas, y el mismo mal código en OOP, la versión de función funciona mejor. entonces, si su código no está escrito mal, no hay pruebas de que OOP mantenga lenta su aplicación. recuerde también que estas cosas "lentas" y "generales" se miden en milisegundos. entonces, si su aplicación no está sirviendo a muchos usuarios (como más de 100 usuarios en un minuto), es posible que no sienta ninguna diferencia.

Answer 5

Trataré de mantener mi respuesta como una adición porque las respuestas de Majd Taby y Coobird son realmente buenas.

Yo era principalmente un programador de procedimientos durante varios años y no peleaba contra la programación OOP, pero nunca realmente vi mucha relevancia ... eso es hasta que comencé a trabajar en un equipo y crear proyectos más importantes y complejos.

OOP realmente brilla, en mi opinión, cuando necesita escribir código delgado, de fácil mantenimiento para aplicaciones más complejas. Y tenga en cuenta que no en todas las situaciones, pero hay algunos en los que el procedimiento no funcionará tan bien.

La mayoría de mis ejemplos de implementaciones de OOP geniales son para proyectos en los que tenía varias cosas que estaban relacionadas pero todas ligeramente diferentes. Sitios con muchos formularios, muchos usuarios, muchos productos, etc.

Todos tienen nombres de comportamiento similares a print(), update(), etc. ... pero encapsulándolos como objetos y variando las implementaciones de los métodos en las clases puedo hacer que mi código en tiempo de ejecución sea muy simple y limpio en todo el sitio. Además, y esta fue la clave, a pesar de tener diferentes comportamientos, pude trabajar con diferentes objetos usando las mismas llamadas a métodos en toda la aplicación. Permite a un segundo desarrollador trabajar en la implementación real mientras yo trabajo en un código más profundo.

No sé si eso ayuda, pero hablando como alguien que estaba en su situación no hace mucho tiempo, me encanta OOP.

Answer 6

OOP le permite crear contenedores estructurados de código, llamados clases, que pueden ser padres/hijos de otro. Esto puede ayudar a crear una aplicación ya que es más fácil de mantener y, si se hace correctamente, puede reducir la redundancia de código. OOP agrega un poco de sobrecarga, pero no es realmente notable y se ve superado por la falta de mantenimiento del código de procedimiento. Si estás escribiendo una gran aplicación, def ve OO, especialmente si va a ser trabajado por muchas personas.

Por ejemplo, supongamos que está diseñando un sitio web sencillo. Podrías crear un objeto de Página. El objeto de página es responsable de ir a la base de datos y obtener varias configuraciones para la página, como metadatos, etiquetas de título o incluso el número de ciertos "componentes" en la página y su tipo (como un control de calendario, un widget , etc.)

Luego, puede crear otra clase, por ejemplo Índice, que amplíe Página. Index sería el índice o la página de inicio. Si tuviera un catálogo de productos, podría tener la página de ampliación de clase Catálogo. Dado que tanto su sección de catálogo como su página de inicio necesitan obtener datos de la base de datos con respecto a los metadatos de la página y la construcción básica de la página, tener 1 objeto que ya lo hace por usted ayuda. En ambas situaciones, la página hace todo el trabajo y obtiene los datos de la página de la base de datos, los carga en variables, que luego son accesibles tanto en su clase de índice como en su clase de catálogo. No tiene que escribir código para ir a la base de datos y volver a obtenerla en cada página que escriba.

Ahora hay otras formas de hacer esto de forma procedural, como con un include. Sin embargo, se encontrará haciendo menos errores y errores. Por ejemplo, puede definir un método abstracto en su clase de página. Esto significa que este método DEBE definirse en cualquier objeto que lo amplíe. Así que supongamos que creó una función setPageAttributes() como resumen en su clase de página. Cuando haces esto, creas una función vacía. Cuando crea su clase de índice, TIENE QUE crear una función setPageAttributes() (con la intención de completarla, como acceder a las variables definidas en la clase de página y usarla para establecer los elementos reales en la página, plantilla o vista que está usando) o recibe un error de PHP.

Si está trabajando con otras personas para escribir su proyecto, los métodos abstractos le dirán a la persona: "Oye, debe definir estas funciones en cualquier código que escriba". Esto obligó a la aplicación a ser consistente.

Finalmente, no puede ir a marcos como formatos MVC si no hace OOP. Si bien no es necesario ir a MVC y existe cierto debate, sí separa todos los componentes de la aplicación y es necesario en entornos donde muchas personas (diseñadores, programadores, empleados de marketing) trabajan en el mismo código.

Answer 7

Digamos que tengo un gran archivo con 50 funciones, ¿por qué voy a querer llamar estos en una clase?y no por function_name(). ¿Debo cambiar y crear el objeto que contiene todas mis funciones ?

Mover a OOP no debería verse como un simple "cambio" en la forma descrita anteriormente.

OOP requiere una forma completamente diferente de pensar sobre la programación que implica reconectar su cerebro. Como volver a cablear un cerebro no ocurre de la noche a la mañana, muchas personas no están dispuestas a exponerse al proceso de cableado requerido. Desafortunadamente, el cableado requerirá una inversión de tiempo y esfuerzo: investigación, tutoriales, prueba y error.

Realmente implica dar un paso atrás y aprender sobre los conceptos detrás de OOP, pero la recuperación valdrá la pena hablar como alguien que pasó por este proceso en los días anteriores a www.

Después de 'obtenerlo' y seguir las mejores prácticas de OOP en su día a día le contará a los demás cómo ha mejorado su vida de programación.

Una vez que realmente comprenda OOP, habrá respondido su propia pregunta.

Answer 8

La respuesta aceptada parece haber olvidado decir que es posible llamar a funciones basadas en un nombre de variable, como en el ejemplo herew:

function drive($the_car){ 
    $the_car(); 
} 

Hay que reconocer que tendría que ser una función de cada vehículo en este caso, pero es mucho más eficiente que la declaración de cambio sugerida.

---

las variables adicionales se pueden suministrar fácilmente como tales:

function operate($the_car,$action){ 
    $the_car($action); 
} 

function ferrari($action){ 
    switch($action){ 
     case 'drive': 
      echo 'Driving'; 
      break; 

     case 'stop': 
      echo 'Stopped'; 
      break; 

     default: return; 
    } 
} 


operate('ferrari','drive'); 

No es una sentencia switch aquí, pero es para suministrar funcionalidad adicional que no estaba en el ejemplo original, por lo que es de ninguna manera una contradicción.

Answer 9

El concepto de OOP se utiliza en PHP, para asegurar el código. Como todas las consultas están escritas en un archivo de función en lugar de un archivo de código para que nadie pueda piratear nuestro código fácilmente. Por lo tanto, es mejor usar clases en PHP en lugar de escribir directamente las consultas.