El modificador private se usa para restringir el acceso fuera de la clase, pero al usar la reflexión, otras clases pueden acceder a campos y métodos privados. Así que me pregunto cómo podemos restringir la accesibilidad si es parte del requisito.
El propósito de los modificadores de acceso es informar a los desarrolladores que escriben código sobre cuál es la interfaz pública de una clase. De ninguna manera son una medida de seguridad y no ocultan ni protegen ninguna información, literalmente.
Para citar Herb Sutter sobre derechos de acceso de clase :
"El problema aquí es la protección contra Murphy frente a la protección contra Maquiavelo ... es decir, la protección contra el uso indebido accidental (que el lenguaje hace muy bien) frente a la protección contra el abuso deliberado (que en realidad es imposible). Al final, si un programador desea lo suficiente como para subvertir el sistema, encontrará una manera "
No, esto es realmente una ventaja importante. Simplemente porque algunos desarrolladores no consideraron que alguien necesitaría acceder a algún estado interno no significa que ningún caso de uso legítimo aparezca jamás. En estos casos, el uso de la Reflexión para realizar una cirugía en un objeto puede ser un último recurso. He tenido que usar esta técnica más de una vez.
Restrinja la accesibilidad aún más subiendo un nivel más: el entorno de ejecución.
No todos los idiomas tienen este concepto, pero al menos con Java puede usar un administrador de seguridad que prohíba hacer accesibles los campos privados. Puede instalar manualmente el administrador de seguridad en tiempo de ejecución, o agregar una política de seguridad en un archivo jar que luego se sella para evitar modificaciones.
Más información sobre cómo hacer esto en Java: Seguridad de reflexión
¿De qué reflexión estás hablando?
En muchos sistemas de reflexión, eludir la encapsulación es una capacidad explícita que su código debe obtener y no tiene por defecto.
Si le preocupa la encapsulación, la solución simple es no usar un sistema de reflexión que no lo conserve.
En Python, no hay modificadores de acceso. La convención es prefijar con un guión bajo los métodos y variables a los que no se espera acceder desde fuera de la clase. ¿Técnicamente le impide acceder a dicho campo desde una clase de terceros? De ningún modo; pero si lo haces, estás solo y te arriesgas a romper algo, sin poder culpar a la otra clase.
En C #, los modificadores de acceso existen, pero aún son solo una convención, una que es aplicada por un compilador, pero aún así es una convención. Esto significa que, técnicamente, todavía se puede acceder y cambiar variables privadas, ya sea a través de Reflection o manipulando directamente la memoria (como entrenadores de juego hacer). La consecuencia es exactamente la misma: si las variables de su clase se cambian a través de la Reflexión de otra clase, o a través de la manipulación de la memoria por otra aplicación, y se rompe algo en su clase, no es su culpa.
Tenga en cuenta que esto, obviamente, crea problemas de seguridad en los que un tercero puede acceder a sus datos de su ; algo que lleva a variantes cifradas de una cadena y estructuras de datos similares. Pero proteger su código de dicho uso está más relacionado con el sistema operativo y restricciones de acceso a nivel de código , y no tiene nada que ver con la Reflexión en sí misma.
Lea otras preguntas en las etiquetas security reflection