Qual é o ponto de visibilidade de OOP em PHP quando Closures and Reflections estão disponíveis?

Considere este código aqui:

final class TinkerWithMe { protected $key1 = 19; private $key2 = 88; } $class = new TinkerWithMe(); $getKeys = function() { return array($this->key1, $this->key2); }; $oldKeys = $getKeys->call($class); $newKey1 = 96; $newKey2 = 42; $setKeys = function() use ($newKey1, $newKey2) { $this->key1 = $newKey1; $this->key2 = $newKey2; }; $setKeys->call($class); 

Por que se preocupar com a visibilidade de OOP quando você pode contornar isso tão facilmente com Fechamentos ou Reflexões?

Existe uma maneira de bloquear esse tipo de coisa que estou perdendo?

Os modificadores de visibilidade não são proteção revestida de ferro ou garantem qualquer tipo de segurança ou qualquer coisa desse tipo. Eles são marcadores de como um pedaço de código destinase a ser usado.

Ao escrever um pedaço de código como uma class, outros pedaços de código vão se encheckboxr com ele; o que significa que você vai escrever outro código que chama methods dessa class ou acessa propriedades dessa class. Para minimizar o acoplamento ao absoluto necessário, você deseja manter a interface pública da class tão pequena quanto possível. Quando você designa algo como public , você está marcando isso “para uso geral”. Essa peça pública deve ser bastante estável e não mudar, ou você corre o risco de quebrar um monte de código acoplado se você mudar isso.

Marcando algo como marcas protected ou private essas partes não são para consumo geral ; ele esclarece que esses detalhes de implementação podem mudar no futuro ou não devem ser usados ​​por outro código “não sabendo”. Isso permite que você refatore mais facilmente aquelas peças mais tarde, conforme necessário, e tenha uma idéia melhor do que outras partes podem quebrar como resultado. Também ajuda a garantir que o estado interno da class seja consistente quando o código externo não modificará diretamente valores internos sem entender completamente como deve fazê-lo.

O PHP irá ajudá-lo a honrar esses marcadores no caso geral, lançando erros quando tentando de maneira idêntica acessar propriedades protected ou private “de fora”; que evita o uso mais acidental e o acoplamento indesejado. O PHP não vai se curvar para trás para garantir que essas propriedades permaneçam inacessíveis em todas as circunstâncias possíveis. Se você está realmente inclinado a triggersr seu próprio pé, seja assim. Talvez você precise fazê-lo para fins de teste; seria contrário à produtividade para absolutamente impedir que você o fizesse.

No mantra de Python :

Todos aqui somos adultos consentindo.

Grande pergunta! Gostaria de adicionar mais alguns pontos

O objective de especificar visibilidade nas linguagens OOP é:

  1. Para mostrar o que as propriedades e os methods devem fazer. Isto é para trazer clareza entre os desenvolvedores sobre como acessar / modificar a propriedade e os methods, para decidir se deve estender a class ou não.
  2. As propriedades que são definidas dentro de sua respectiva class são validadas e definidas para corrigir valores e é seguro ser usado dentro da Classe sem verificar o tipo de propriedade.
  3. Não é uma maneira infalível de proteger os dados da modificação.

O Propósito dos Closures é lançar uma peça de function em uma variável ou outra function para executar alguma atividade de vez em quando. Em vez de dedicar um código de seção separado no escopo global para executar uma ação de vez em quando e não olhar para isso, você pode usar fechamentos.

As reflexões são destinadas a introspecção de objects para conhecer suas propriedades, methods, aulas, etc. É útil identificar dependencies. Larvel usa reflection para executar a injeção de dependência de objects.

Sim, como você disse, você pode usar Closures e Reflection para trabalhar em torno da visibilidade, mas deve ser visto como um recurso de idioma em vez de uma falha de design, pois nenhuma linguagem pode proteger dados 100%