una - que significa class en php
¿Por qué usar PHP OOP sobre funciones básicas y cuándo? (10)
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?
Digamos que tengo un archivo grande con 50 funciones, ¿por qué querré llamarlas en una clase? y no por nombre_función (). ¿Debo cambiar y crear un objeto que contenga todas mis funciones?
Pasar a OOP no debería verse como un simple "cambio" en la forma en que usted describe arriba.
OOP requiere una forma completamente diferente de pensar acerca de 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 de la inversión valdrá la pena como persona 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 otros cómo su vida de programación ha cambiado para mejor.
Una vez que realmente comprenda OOP, habrá respondido su propia pregunta.
El concepto de OOP se usa 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.
El uso del oop le proporciona los siguientes beneficios:
- Estructuración
- Reusabilidad
- Facil mantenimiento
- Encapsulación de los datos
Llegando al punto de hacer un gran archivo con la función 50. Puede hacerlo, pero cuando se trata del flujo de la función y cómo los datos de datos se unirán entre cada función será un problema mayor.
También para el mantenimiento futuro, si desea reemplazar la mayor parte del flujo, confíe en mí, debe ir a cada función y jugar a su alrededor. Además, nunca se sabe cómo se usan sus funciones en otra parte del código. Entonces la programación orientada a objetos siempre es recomendable.
Para obtener información detallada sobre los beneficios, puede leer mi publicación en OOP en PHP
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 lugares más bonitos de la OMI que brilla en OO, le permite deshacerse del código de tipo de encendido. Considerar:
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();
}
El polimorfismo permitirá que ocurra el tipo adecuado de "conducción", en función de la información de tiempo de ejecución.
Notas sobre el polimorfismo:
El segundo ejemplo aquí tiene algunas premisas: Es decir, todas las clases de automóviles extenderán una clase abstract o implementarán una interface .
Ambos le permiten forzar la extensión o implementación de clases para definir una función específica, como drive() . Esto es muy poderoso ya que le permite drive() todos los automóviles sin tener que saber a cuál conduce; esto 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.
Siempre que se asegure de que todos sus automóviles específicos amplíen el car clase abstracta o implementen una interfaz como canBeDriven (ambos deben declarar el método drive() ), puede simplemente llamar al método drive() en un objeto que usted sabe que es un automóvil (pero no qué tipo de automóvil) sin temor a que no se defina, ya que PHP le arrojará errores fatales hasta que usted defina esos métodos en sus clases específicas de automóvil.
La respuesta aceptada parece haber omitido afirmar que es posible llamar a funciones basadas en un nombre de variable como en el ejemplo aquí:
function drive($the_car){
$the_car();
}
Es cierto que debería haber una función para cada automóvil en esta instancia, pero es mucho más eficiente que la declaración de cambio sugerida.
Se pueden suministrar variables adicionales 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'');
Aquí hay una declaración de cambio pero es para proporcionar una funcionalidad adicional que no estaba en el ejemplo original, por lo que no es una contradicción.
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 verdad) que si escribe un código incorrecto en funciones clásicas y el mismo código incorrecto 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.
OOP le permite crear contenedores estructurados de código, llamados clases, que pueden ser padres / hijos de cada uno. 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 simple. 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 maneras de hacer esto de forma procesal, 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, necesitas definir estas funciones en cualquier código que escribas". Esto obligó a la aplicación a ser consistente.
Finalmente, no puede ir a frameworks 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.
Si tiene 50 funciones en lugar de 50 métodos estáticos en la clase Utilidades, "contaminará" el espacio de nombres global.
Usando una clase con 50 métodos estáticos, los nombres de los métodos son locales para su clase.
Trataré de mantener mi respuesta como una adición porque las respuestas de Majd Taby y Coobird son realmente buenas.
Principalmente fui programador de procedimientos durante varios años y no peleé contra la programación OOP, pero nunca vi mucha relevancia ... eso es hasta que comencé a trabajar en un equipo y a desarrollar proyectos más importantes y complejos.
OOP realmente brilla, en mi opinión, cuando necesitas escribir un código delgado, fácil de mantener 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 relacionadas pero todas ligeramente diferentes. Sitios con muchas formas, muchos usuarios, muchos productos, etc.
Todos tienen nombres de comportamiento similares como 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 utilizando las mismas llamadas a métodos a lo largo de 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.
Usar 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.
(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 solo está realizando una serie de funciones en orden, 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 va a tratar con muchos elementos diferentes (como archivos o cualquier otra representación de, bueno, objetos) entonces un enfoque orientado a objetos sería mejor.
Por ejemplo, si tiene un montón de Car y quiere que drive , entonces en procedimientos, puede hacer algo en la línea de:
drive_car(first_car)
drive_car(second_car)
Donde, como en OOP, el Car puede conducir por 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 tanto subclases como Car , pueden tener una funcionalidad común.
Realmente se reduce al tipo de problema que hace que sea un enfoque de procedimiento mejor que orientado a objetos y viceversa.
Aparte de la cuestión de los procedimientos u orientada 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á bien escrito y es fácil de mantener.