Pregunta

Hay muchos debates sobre si la Programación Orientada a Objetos es buena o no.Pero usar programación orientada a objetos en PHP es más lento.¿Sería una buena opción utilizar programación procedimental y una velocidad más rápida y programación orientada a objetos con una velocidad más lenta (ya que las clases deben iniciarse cada vez que se carga una página y los sitios web grandes comenzarán a volverse lentos)?

Más importante aún, ¿sería bueno envolver cosas dentro de una clase y usar funciones estáticas o sería mejor tener muchas funciones mentirosas con un prefijo, por ejemplo:wp_función().

¿Fue útil?

Solución

Sí, es casi siempre una buena idea utilizar programación orientada a objetos. Esto se debe a la POO es un estilo de codificación, y estilos de codificación en su mayor parte son fácilmente capaces de ser transferido al otro lado de idiomas.

Las personas no utilizan codificación de estilos, ya que utilizan un determinado idioma. La gente utiliza estilos de codificación debido a que el estilo de codificación ofrece métodos buenos para hacer cosas que les parecen deseables. Por lo tanto, siempre y cuando los elementos básicos están ahí (herencia, propiedades de clase, etc.), siempre será viable a escribir en ese estilo de codificación.

No, el uso de las funciones de procedimiento para acceder a ellos probablemente no es una buena idea. Esto se debe, probablemente tendrá que hacer algo como esto para mantener el estado.

function myFunc()
{
    global $class;
    $class->doMethod();
}

function myFunc2()
{
    global $class;
    $class->doMethod2();
}

Esta es una mala idea, ya que crea una tonelada de estado global.

Otros consejos

Si la razón que usted está preocupado acerca del uso de OO con PHP es la velocidad, no temas: PHP es un lenguaje lento por todas partes. Si estás haciendo algo que es lo suficientemente intensivo del procesador para la pérdida de velocidad desde el uso de objetos a la materia, no se debe utilizar PHP en absoluto.

En cuanto a las funciones estáticas, esto es una opción de diseño, pero me gustaría errar en el lado de evitar clases compuesta en su totalidad de las funciones estáticas. Realmente no hay ninguna ventaja para la vuelta prefijos, y el uso de una construcción sólo porque es allí no es una idea buena.

Los mismos argumentos sobre el rendimiento se hicieron con Objective C y C++ en el pasado.Y la respuesta a ese problema fue aprovechar la memoria disponible y la potencia de procesamiento que continuamente son mayores, mejores y más rápidas.

Sí, OO requiere más recursos para ejecutarse.Pero los beneficios de usar OO superan el costo de hardware (que probablemente sea insignificante) de soportar aplicaciones OO.

Sin embargo, es bueno preocuparse por el rendimiento del software.Sin embargo, si miramos bajo el capó de lo procesal vs.oo como punto de partida es un poco equivocado.Para empezar, debe concentrarse en escribir código eficiente, ya sea de procedimiento u OO (y ambos son relevantes).

Tenga en cuenta que, aunque PHP puede no ser la plataforma más rápida que existe (Java, por ejemplo, patea el trasero), PHP se utiliza para impulsar algunos de los sitios web con mayor tráfico en Internet:es decir, Facebook.

Si tiene alguna otra duda sobre PHP y OO, mire Zend y Magento (basado en Zend).Magento es un MUY En una plataforma que consume muchos recursos, el uso de memoria puede superar los 36 MB por instancia.Sin embargo, la plataforma en sí es capaz de manejar millones de visitas.Esto se debe a que un entorno de servidor configurado correctamente con una buena cantidad de recursos de hardware hace que todos los beneficios del uso de OO superen con creces el costo del servidor en sí.Pero en un mundo de computadoras agrupadas, NO usar la potencia de procesamiento y la memoria (responsablemente) disponibles es, en mi humilde opinión, una locura clínica.

En mi humilde opinión, los desarrolladores de PHP no deben tratar de ir únicamente una dirección. (Procedimiento vs orientado a objetos) En algunos casos, todo lo que necesita es un par de funciones globales, otras veces es más beneficioso para los objetos de uso. No trate de fuerza de todo un modo u otro, ser flexible y utilizar lo que funciona mejor para cada situación.

Estoy totalmente en desacuerdo con la respuesta de Chacha102.

Una respuesta adecuada a esta pregunta podría llenar varios libros -. No importa un puesto 20 de la línea aquí

Ambos métodos tienen sus ventajas y desventajas. Yo recomendaría a cualquiera que quiera considerarse un buen programador de tener una importante experiencia en la programación de procedimiento, no de procedimiento y orientado a objetos. Así como la experiencia con diferentes metodologías como SCRUM, cascada y RAD.

En cuanto a la idoneidad para los PHP OO vs codificación procesal, sin duda las raíces de la lengua son en este último (pero tenga en cuenta que tanto Java y ASP son híbridos en lugar de verdaderos lenguajes orientados a objetos).

peronally, tiendo a escribir el código de procedimiento cuando tenga que producir algo que puede ser muy simple o debe tener su comportamiento para ser Thouroughly definida y predecible. Sin embargo, cuando la escritura de código complejo en el que el comportamiento variará en gran medida en tiempo de ejecución, encuentro OO ser mucho más eficiente en términos de tiempo de desarrollo -. A pesar del diseño está basado en un conjunto finito de casos de uso

Para argumentar que siempre se debe escribir el código de procedimiento porque va a correr más rápido que el código OO:

1) no es necesariamente cierto 2) ignora totalmente el costo relativo del tiempo de desarrollo frente a los costes de hardware

  

¿sería bueno para material de envoltura dentro de una clase y funciones estáticas uso

Dado que los espacios de nombres ya están disponibles en PHP, esta es una manera muy sucia para evitar colisiones de espacio de nombres y no es algo que yo recomendaría.

C.

No hay ninguna respuesta realmente perfecto, ya que depende de muchas variables desconocidas, y entonces no tiene que ser todo o nada.

Por ejemplo, si divide su aplicación en el modelo MVC, usted podría tener su modelo sea OO pero mantener el controlador más simplista de procedimiento.

Se podría utilizar clases como un medio de simples funciones de grupo común estáticas, o usted podría tomar mucho más lejos en el patrón de registro activo.

Si usted está construyendo un pequeño formulario web de una sola página que los brotes fuera un POST en un correo electrónico, que realmente no necesitan OO -. No sea que tal vez incluya una clase de correo existente al apalancamiento

Nadie puede darle asesoramiento adecuado sin entender el proyecto que estamos llevando adelante.

Dicho esto, si su única preocupación es la velocidad, entonces OO sea un poco más lento. Y hay un montón de razones que hacen que usted puede hacer en PHP incluso procedimental en cierta mímica de las ganancias OO. Pero a menos que usted está tomando en un proyecto de gran envergadura, la sobrecarga añadida nunca gran cosa. Y por el tiempo que tiene un gran proyecto, los profesionales de OO podría superar las desventajas de sus gastos generales.

Yo tenía curiosidad de este mismo. Por desgracia después de cambiar mi código de procedimiento a oop me encontré con algunos puntos de referencia y no antes.

Este es el código de referencia.

class game{
  function maxp($val){
    return max(0,pow($val,0.5));        
  }
}

$game = new game;

for($i=0;$i<100000;$i++){
  $game->maxp(100);
  //game::maxp(100);
}

Resultados de la OOP oscilaron entre 0,13 y 0,2 segundos;

Resultados de procedimiento variaron entre 0,08 y 0,1 segundos.

Los resultados se mantuvo constante durante un buen periodo de tiempo.

Os animo a ejecutar sus propias pruebas.

PHP 5.4.3

OOP tiene más méritos que su de-méritos. Ver PHP OOP, ¿cuáles son los beneficios? . También ver por programación orientada a objetos vs PP en PHP .

Sí como su aplicación crece .. (y será) que le ahorrará muchas horas de frustración. Y repitiendo (copiar pegar código de todo el lugar) ..:)

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top