Cuándo deberíamos usar la clase y cuándo no debemos

Question

Las clases son útiles y todas, pero cuando estoy escribiendo una clase siempre pienso en ello como una piedra dura en mi guión. Siento que las clases rara vez deberían usarse. Pero al mismo tiempo, todos somos conscientes del paradigma de OOP.

¿Una secuencia de comandos nunca debe tener funciones gratuitas? ¿Debería usar miles de clases solo para hacer que el script esté más limpio? ¿Y qué hay de las actuaciones? ¿Requiere class::method() mucho más tiempo que un simple function()? ¿Cuál es el verdadero significado de OOP? Estoy un poco confundido.

Desde que descubrí OOP, no puedo ver funciones aleatorias. Estoy obsesionado. No puedo ver las funciones que no tienen clase principal. Prefiero crear una clase con solo un método y luego ver esa función solo. ¿Es correcto? ¿Hay ejemplos de CMS pura OOP por ahí?

Answer 1

Lo más importante para un programador en PHP, en mi opinión, aparte de su experiencia es su conjunto de herramientas. Es decir, código que ha escrito por dentro y por fuera, hacia atrás y hacia delante desde tiempos inmemoriales.

Para mí, en este caso, la ventaja de OOP en claro. Tener una clase que sabes que siempre preformará lo que quieres a través de métodos simples es mucho más fácil para ti y para los miembros del equipo, entonces es simplemente llamando a una multitud de funciones estáticas. Si bien podría argumentar que una biblioteca de función satic incluye el mismo propósito, en mi opinión las clases son mucho más fáciles de leer y entender. Por ejemplo, en mi clase de sesión personalizado un programador puede mirar mi código y ver,

$my_session = new session(); 
$my_session->start(); 

if (($session_errno = $my_session->error()) !== FALSE) 
{ 
    //DO SOMETHING BECAUSE OF A SESSION ERROR 
} 

y fácil de entender que las sesiones en esta aplicación son manejados a través de nuestra clase de sesión personalizado, y debe devolver algún tipo de éxito/fracaso sin haber examinado nunca la biblioteca/clase.Mientras tanto, una llamada de este tipo,

session_start(); 

if (session_error()) 
{ 
    //DO SOMETHING BECAUSE OF A SESSION ERROR 
} 

no dejan claro que session_start() no es un gestor de sesiones de PHP por defecto, pero que va a llamar a las funciones definidas en session_set_save_handler() que fue incluido en alguna lista de mega incluye mundial eso podría no ser fácil de localizar en una aplicación grande. Tampoco está tan claro que session_error() es una función que devuelve un error establecido por el manejador de sesión personalizado, frente a una función que puede buscar activamente problemas de sesión en una sesión ya generada y es completamente independiente de la sesión predeterminada de PHP.

Esto no es un gran ejemplo, pero creo que es una buena idea. No entré en detalles sobre la bondad que está protegiendo los datos de la aplicación en conjunto, la herencia y todo lo demás que hace que OOP sea útil.

Pero rápidamente, imagine una clase que accede a la base de datos MYSQL de una aplicación. Se emplea mucho tiempo diseñando la clase para usar declaraciones preparadas, registrar errores y proporcionar la lógica adecuada al programador según sea necesario. Un equipo puede preocuparse menos por los problemas de acceso a la base de datos simplemente llamando a las funciones públicas de "acceso a datos" de la clase sin mucha preocupación por errores fatales, mala lógica o SQL peligroso (inyecciones y demás).

Todo esto se puede hacer con funciones estáticas como usted sugiere, PERO cada función en esa biblioteca estática está expuesta a la aplicación como un todo, mientras que solo las funciones públicas y 'SEGURO' están expuestas a la aplicación que utiliza una base de datos Objeto de acceso. El programador no puede llamar accidentalmente a una función peligrosa que si no se ha inicializado correctamente por otras funciones podría causar problemas importantes, ni el programador podría suprimir deliberadamente errores u otros datos protegidos por la clase como podrían con un montón de funciones estáticas y variables globales.

Si bien una buena aplicación se puede diseñar sin ningún objeto, un buen programador debe disfrutar de la usabilidad, la extensibilidad y las protecciones que ofrecen los objetos cuando corresponda.

Me iré con mi metáfora final. Los objetos son como máquinas y herramientas especializadas dentro de una fábrica. Si bien la fábrica tiene varias de estas herramientas exclusivas en su línea de ensamblaje, desde frenos plegables simples hasta máquinas CNC y robots automáticos, son solo una pequeña parte del equipo que existe para ayudar a los trabajadores y gerentes más numerosos, nuestra estática funciones, haga el trabajo de construir un mejor automóvil, camión o bicicleta.

Answer 2

Creo que tiene una mala visión de la programación OOP porque no lo hagas nunca. Quake 3 se amplian usando pura C sin ninguna clase y programación orientada a objetos, entonces esta es una prueba de que se pueden hacer cosas buenas sin necesidad de utilizar programación orientada a objetos.

Pero si lo desea, puede usarlo. Herencia en las clases tienen una pequeña funcionalidad en la práctica lógica de programación comercial, mucho mejor en la programación de marcos.

Si decide programar con OOP, escriba objetos pequeños con funciones pequeñas que haciendo cosas pequeñas, no grandes clases no legibles con funciones largas no intuitivas, entonces se mantendrá limpio en su código.

Answer 3

Tener un vistazo a esto:

clases son poco más que un contenedor para las variables y funciones que afectan a esas variables, pero puede ser muy útil para la construcción de pequeñas componentes - casi programas miniture. La diferencia es que no necesita para pagarlas y se pueden conectar fácilmente a la mayoría de las secuencias de comandos - Solo se requiere o incluir una declaración en la parte superior. Una clase describe un 'objeto'. Un objeto es una colección de objetos más pequeños, solo como en una clase.

Reference

Answer 4

Si se piensa en sus objetos pesados ​​como rocas, que podría ser una buena cosa. Dado que php no es muy fácil por naturaleza (excepto algunas extensiones predeterminadas), hay funciones de procedimiento suficientes, aproximadamente 6000, ¿no?

Te animo a que continúes con OOP. Cientos de clases parecen exageradas sin embargo. Para empezar, coloque todo lo que necesita en un objeto y divídalo en subclases cuando corresponda.

Answer 5

No hay una respuesta simple para esto.

Si bien, en general, debe apegarse a un enfoque funcional u OO, una de las cosas buenas de PHP en comparación con, por ejemplo, Java, es que permite funciones como entidades de primera clase.

Lo más importante que debe recordar es que escribe programas en un lenguaje y un estilo que los hace legibles para el ser humano. El hecho de que la computadora pueda analizarlos es casi una coincidencia.

Sin duda, la sobrecarga de llamar a un método estático frente a una función no debe ser una consideración, y usted es definitivamente culpable de una optimización prematura. Si le preocupa esto, ¿por qué no lo mide usted mismo? Descubrirá que si bien es más lenta, la diferencia es muy pequeña, y no debe anular los objetivos principales al escribir el código (es decir, debería funcionar, debe ser lo más claro posible cómo funciona, no debe tener ningún lado -efectos).

Answer 6

No utilice OOP solo para agrupar juntas un conjunto de funciones aparentemente relacionadas.

Use OOP para tener representaciones lógicas de "cosas" con estado y sin estado que puedan ser manipuladas, tengan atributos o se usen de varias maneras.

No use OOP solo porque alguien aquí dice que debe hacerlo.

Utilice OOP porque ve el beneficio en data encapsulation. No use OOP si cree que hará feliz a su jefe.

Usa OOP porque obtienes que un Tacoma es un Toyota es un PassengerVehicle es un Vehículo.

No utilice OOP hasta que haya al menos revisado los patrones de diseño de la Banda de los Cuatro - los beneficios se vuelven más claros.

Use OOP porque desea proporcionar a las personas que desarrollarán con esta clase interfaces fáciles de usar.