O Reflection é uma desvantagem, pois as variáveis ​​privadas não podem ser restringidas?

O privatemodificador é usado para restringir o acesso fora da classe, mas usando a reflexão outras classes podem acessar métodos e campos privados. Então, eu estou querendo saber como podemos restringir a acessibilidade, se isso faz parte dos requisitos.

O objetivo dos modificadores de acesso é informar aos desenvolvedores que escrevem código sobre qual é a interface pública de uma classe. Eles não são de forma alguma uma medida de segurança e não ocultam nem protegem literalmente nenhuma informação.

Para citar Herb Sutter sobre os direitos de acesso à classe :

"A questão aqui é proteger contra Murphy versus proteger contra Maquiavel ... ou seja, proteger contra uso indevido acidental (que a língua faz muito bem) vs. proteger contra abuso deliberado (que é efetivamente impossível). No final, se um programador quer o suficiente para subverter o sistema, ele encontrará uma maneira "

Não, isso é realmente uma vantagem importante. Simplesmente porque algum desenvolvedor não considerou que alguém precisaria acessar algum estado interno não significa que nenhum caso de uso legítimo seja exibido. Nesses casos, o uso do Reflection para realizar cirurgia em um objeto pode ser o último recurso. Eu tive que usar essa técnica mais de uma vez.

Você restringe ainda mais a acessibilidade subindo mais um nível: o ambiente de execução.

Nem todas as linguagens têm esse conceito, mas pelo menos com Java você pode usar um gerenciador de segurança que proíbe a disponibilização de campos privados. Você pode instalar manualmente o gerenciador de segurança em tempo de execução ou adicionar uma política de segurança em um arquivo jar que é selado para evitar modificações.

Mais informações sobre como fazer isso em Java: Reflection Security

De que reflexão você está falando?

Em muitos sistemas de reflexão, contornar o encapsulamento é um recurso explícito que seu código precisa obter e não possui por padrão.

Se você está preocupado com o encapsulamento, a solução simples é simplesmente não usar um sistema de reflexão que não o preserve.

No Python, não há modificadores de acesso. A convenção é prefixar com um sublinhado os métodos e variáveis ​​que não se espera que sejam acessados ​​de fora da classe. Tecnicamente, isso impede que você acesse esse campo de uma classe de terceiros? De modo nenhum; mas, se o fizer, estará por sua conta e correrá o risco de quebrar alguma coisa, sem poder culpar a outra classe.

No C #, existem modificadores de acesso, mas eles ainda são apenas uma convenção - que é imposta por um compilador, mas ainda é uma convenção. Isso significa que, tecnicamente, ainda é possível acessar e alterar variáveis ​​privadas, através do Reflection ou violando diretamente a memória (como fazem os treinadores de jogos ). A conseqüência é exatamente a mesma: se as variáveis ​​da sua classe forem alteradas através do Reflection de outra classe, ou através da violação de memória de outro aplicativo, e isso interromper algo na sua classe, a culpa não é sua.

Observe que, obviamente, isso cria problemas de segurança nos quais terceiros podem acessar seus dados; algo que leva a variantes criptografadas de uma string e estruturas de dados semelhantes. Mas proteger seu código contra esse uso está relacionado a restrições de acesso ao sistema operacional e ao nível do código , e não tem nada a ver com o Reflection em si.