El mensaje será fundamental en la programación: objetos globales. Diría que este es un tema científico que me gustaría discutir. Entonces, para no "disparar sus propias piernas", los programadores no programan en el campo global. Ok, todo es claro y extremadamente simple, ¿te detienes en esto? No en estas cosas. Como saben, cualquier acción provoca una cadena de eventos y consecuencias lógicas.
Primero, ¿por qué crear un dogma que no puedes crear? En su lugar, creemos una función stop_globals (), por ejemplo, para el lenguaje PHP. El marco, al comienzo de la ejecución de su código, puede ejecutarlo, y los intentos adicionales de trabajar con el alcance global causarán errores de PHP. ¿Es buena esta solución?
Eso está lejos de todo lo que podría discutirse.
La razón principal de la existencia del dogma anterior es que es posible sobrescribir accidentalmente los valores de las variables globales, y esto, a su vez, puede conducir a errores de localización difíciles en el programa. ¿Y si puede usar variables globales para leer, pero no para escribir?
Prestemos atención al universo que nos rodea. Hay objetos globales en él: espacio, tiempo, materia, energía, posiblemente materia oscura y energía. Del mismo modo, según mi experiencia en la programación web, hay una serie de objetos para los que es inconveniente usar la inyección de dependencia, y dichos objetos son esencialmente globales. Este es un objeto de comunicación de base de datos, el objeto USUARIO y otros. Para trabajar con tales objetos, en PHP, uno podría introducir la función super ('sky', 'user'), que haría que las variables $ sky y $ user sean superglobales, como $ _GET o $ _POST.
Tal solución no es peor que el dogma tradicional "es imposible programar en el campo global", ya que escribir datos en tales variables se detectará inmediatamente y PHP dará un error, y la ventaja es la siguiente:
- Conceptualmente, los objetos globales siguen siendo globales, el programa parece más simple
- Este enfoque es más productivo. Es mucho más rápido acceder a una variable directamente que pasar su valor a través de la pila de antemano. Esto significa la pila del procesador, que utilizan los compiladores para pasar parámetros de función. De una forma u otra, la implementación del patrón DI tiene una sobrecarga en los recursos utilizados.
Como saben, el proyecto PHP se posiciona como un elefante, en vista del hecho de que proporciona muchos enfoques de programación, una gran cantidad de funciones y clases, una gran cantidad de código experimental que puede evaluarse con el tiempo y puede desarrollarse o eliminarse en el futuro. En este sentido, pido a las personas de libre pensamiento que expresen su opinión razonada sobre las preguntas:
- ¿Apoya la introducción de las funciones experimentales super () y stop_globals ()?
- ¿Qué opinas de la idea anterior en su conjunto?
No hay guerra santa, gracias.
En conclusión, me gustaría señalar mi observación sobre laravel y los peligros de los patrones de programación. Como saben, laravel se llama el
"almacén de antipatterns" . Creo que este hecho, así como el libre pensamiento de su autor, permitió que este proyecto se volviera tan popular como es. Los patrones son buenos para que los programadores se comuniquen, para señalar alguna entidad de programación. Pero dañan, confunden a los programadores, no permiten que los programas sean efectivos. Hagamos que la programación sea más fácil.