The private modifier is used to restrict access outside the class, but using reflection other classes can access private method and fields. So I am wondering how we can restrict accessibility if it is part of requirement.
8
The purpose of access modifiers is to inform developers writing code about what is the public interface of a class. They are not in any way a security measure and they do not literally hide or secure any information.
4
To quote Herb Sutter on class access rights:
“The issue here is of protecting against Murphy vs. protecting against Machiavelli… that is, protecting against accidental misuse (which the language does very well) vs. protecting against deliberate abuse (which is effectively impossible). In the end, if a programmer wants badly enough to subvert the system, he’ll find a way”
6
No, this is actually an important advantage. Simply because some developer didn’t consider that anyone would need access to some piece of internal state doesn’t mean that no legitimate use case will ever turn up. In these cases, using Reflection to perform surgery on an object can be a last resort. I’ve had to use this technique more than once.
1
You restrict accessibility even more by going up one more level: the execution environment.
Not all languages have this concept, but at least with Java you can use a security manager that forbids making private fields accessible. You could manually install the security manager at runtime, or add a security policy in a jar file which is then sealed to prevent modification.
More information on doing this in Java: Reflection Security
What reflection are you talking about?
In many reflection systems, circumventing encapsulation is an explicit capability that your code needs to obtain, and doesn’t have by default.
If you are concerned about encapsulation, the simple solution is to just not use a reflection system that doesn’t preserve it.
In Python, there are no access modifiers. The convention is to prefix by an underscore the methods and variables which are not expected to be accessed from outside of the class. Does it technically prevent you from accessing such field from a third-party class? Not at all; but if you do, you’re on your own and you take the risk of breaking something, without being able to blame the other class.
In C#, access modifiers exist, but they are yet only a convention—one which is enforced by a compiler, but still a convention. This means that technically, one can still access and change private variables, either through Reflection or by tampering directly the memory (like game trainers do). The consequence is exactly the same: if the variables of your class are changed through Reflection from another class, or through memory tampering by another application, and it breaks something in your class, it’s not your fault.
Note that this, obviously, creates security issues where a third-party can access your data; something which leads to encrypted variants of a string and similar data structures. But protecting your code from such usage is more related OS and code-level access restrictions, and has nothing to do with Reflection per se.
1