A mensagem será fundamental na programação - objetos globais. Eu diria que esta é uma questão científica que eu gostaria de discutir. Portanto, para não “atirar nas próprias pernas”, os programadores não programam no campo global. Ok, tudo é claro e extremamente simples, me debruço sobre isso? Não neste material. Como você sabe, qualquer ação causa uma cadeia de eventos e consequências lógicas.
Primeiro, por que criar um dogma que você não pode criar? Em vez disso, vamos criar uma função stop_globals (), por exemplo, para a linguagem PHP. A estrutura, no início da execução de seu código, pode executá-lo, e novas tentativas de trabalhar com o escopo global causarão erros de PHP. Esta solução é boa?
Isso está longe de tudo o que poderia ser discutido.
A principal razão para a existência do dogma acima é que existe a possibilidade de sobrescrever acidentalmente os valores das variáveis globais, e isso, por sua vez, pode levar a erros de localização difíceis no programa. E se você pode usar variáveis globais para leitura, mas não para escrever?
Vamos prestar atenção ao universo que nos rodeia. Existem objetos globais nele: espaço, tempo, matéria, energia, possivelmente matéria escura e energia. Da mesma forma, com base na minha experiência em programação na web, há vários objetos para os quais é inconveniente usar a Injeção de Dependência, e esses objetos são essencialmente globais. Este é um objeto de comunicação do banco de dados, o objeto USER e outros. Para trabalhar com esses objetos, no PHP, pode-se introduzir a função super ('sky', 'user'), que tornaria as variáveis $ sky e $ user super globais, como $ _GET ou $ _POST.
Essa solução não é pior que o dogma tradicional "é impossível programar no campo global", pois a gravação de dados nessas variáveis será detectada imediatamente e o PHP dará um erro, e a vantagem é a seguinte:
- Objetos conceitualmente globais permanecem globais, o programa parece mais simples
- Essa abordagem é mais produtiva. É muito mais rápido acessar uma variável diretamente do que passar seu valor pela pilha antes. Isso significa a pilha do processador, usada pelos compiladores para transmitir parâmetros de função. De uma maneira ou de outra, a implementação do padrão de DI tem sobrecarga nos recursos utilizados.
Como você sabe, o projeto PHP se posiciona como um elefante, tendo em vista que fornece muitas abordagens à programação, um grande número de funções e classes, uma abundância de código experimental que é avaliado ao longo do tempo e pode ser desenvolvido ou excluído no futuro. A esse respeito, peço às pessoas de pensamento livre que expressem sua opinião fundamentada sobre as perguntas:
- Você apoia a introdução das funções experimentais super () e stop_globals ()?
- O que você acha da idéia acima como um todo?
Não há guerra santa, obrigado.
Concluindo, gostaria de observar minha observação sobre o laravel e os perigos dos padrões de programação. Como você sabe, o laravel é chamado de
"depósito de antipadrões" . Acredito que esse fato, assim como o pensamento livre de seu autor, permitiu que esse projeto se tornasse tão popular quanto ele. Os padrões são bons para os programadores se comunicarem, para apontarem para alguma entidade de programação. Mas eles prejudicam, confundindo os programadores, não permitindo que os programas sejam eficazes. Vamos facilitar a programação.