Hi,
Does reflection breaks the idea of private methods, because private methods can be access outside of the class? (Maybe I dont understand the meaning of reflection or miss something else, please write) http://en.wikipedia.org/wiki/Reflection_%28computer_science%29
Edit: If relection breaks the idea of private methods - does we use private methods only for program logic and not for program security?
Thanks
I think this is a matter of opinion, but if you are using reflection to get around the encapsulation put in place by a developer on a class, then you are defeating the purpose.
So, to answer your question, it breaks the idea of encapsulation (or information hiding), which simply states that private properties/methods are private so they cant be mucked with outside the class.
Yes, reflection breaks this idea. Native languages also have some tricks to break OOP rules, for example, in C++ it is possible to change private class members using pointer tricks. However, by using these tricks, we get the code which can be incompatible with future class versions - this is the price we pay for breaking OOP rules.
Yes. Reflection breaks encapsulation principle. That's not only to get access to private members but rather expose whole structure of a class.
Yes, Reflection could be used to violate encapsulation and even cause incorrect behavior. Keep in mind that the assembly needs to be trusted to perform reflection, so there are still some protections in place.
Reflection does provide a way to circumvent Java's Access Protection Modifiers and therefore violates strict encapsulation as it realised in C++ and Java. However this does not matter as much as you might think.
Access Protection Modifiers are intended to assist programmers to develop modular well factored systems, not to be uncompromising gate keepers. There are sometimes very good reasons to break strict encapsulation such as Unit Testing and framework development.
While it may initially be difficult to stomach the idea that Access Protection Modifiers are easily circumventable, try to remember that there are many languages (Python, Ruby etc.) that do not have them at all. These languages are used to build large and complex systems just like languages which do provide access protection.
There is some debate on whether Access Protection Modifiers are a help or a hindrance. Even if you do value access protection treat it like a helping hand, not the making or breaking of your project.
It's like your house. Locks only keep out honest people, or people who aren't willing to pick your lock.
Data is data, if someone is determined enough, they can do anything with your code. Literally anything.
So yes, reflection will allow people to do things you don't want them to do with your code, for example access private fields and methods. However, the important thing is that people will not accidentally do this. If they're using reflection, they know they're doing something they probably aren't intended to do, just like no one accidentally picks the lock on your front door.
Yes it breaks the encapsulation, if you want it to. However, it can be put to good use - like writing unit tests for private methods, or sometimes - as I have learned from my own experience - getting around bugs in third party APIs :)
Note that encapsulation != security. Encapsulation is an object oriented design concept and is only meant for improving the design. For security, there is SecurityManager in java.
It does, as other already stated.
However, I remember that in Java there can be a security manager active, that could prevent you from accessing any private methods, even with reflection, if you don't have the rights to do so. If you run your local JVM, such a manager is usually not active.
Reflection makes it possible for any CLR class to examine and manipulate properties and fields of other CLR classes, but not necessarily to do so sensibly. It's possible for a class to obscure the meaning of properties and fields or protect them against tampering by having them depend in non-obvious fashion upon each other, static fields, underlying OS info, etc.
For example, a class could keep in some variable an encrypted version of the OS handle for its main window. Using reflection, another class could see that variable, but without knowing the encryption method it could not identify the window to which it belonged or make the variable refer to another window.
I've seen classes that claim to act as "universal serializers"; they can be very useful if applied to something like a data-storage-container class which is missing a "serializable" attribute but is otherwise entirely straightforward. They will produce gobbledygook if applied to any class whose creator has endeavored to obscure things.
Yes, but it is not a problem.
Encapsulation is not about security or secrets, just about organizing things.
Reflection is not part of 'normal' programming. If you want to use it to break encapsulation, you accept the risks (versioning problems etc)
Edit: Yet another metaphor.
In some gardens or parks the flowerbeds are surrounded by fences. They are usually not very tall, sometimes just knee-height. Those fences are Encapsulation. Telling you where (not) to go.
Gardeners frequently step over those fences. They are doing maintenance. That is what Reflection is for.
Reflection should only be used when there are no better (less invasive) ways to accomplish something.
Reflection is for system-level 'tooling' like persistance mapping and should be tucked away in well tested libraries. I would find any use of reflection in normal application code suspect.
I started with "it is not a problem". I meant: as long as you use reflection as intended. And careful.
Yes, it does break encapsulation. But there are many good reasons to use it in some situations.
For example:
I use MSCaptcha in some websites, but it renders a < div> around the < img > tag that messes with my HTML. Then i can use a standard < img> tag and use reflection to get the value of the captcha's image id to construct a URL.
The image id is a private Property but using reflection i can get that value.
access control through private/protected/package/public is not primarily meant for security.
it helps good guys to do the right thing, but doesn't prevent bad guys from doing wrong things.
generally we assume others are good guys, and we include their code into our application without though.
if you can't trust the guy of a library you are including, you are screwed.
do we use private methods only for program logic and not for program security?
It is not clear what you mean by "program security". Security cannot be discussed in a vacuum; what resources are you thinking of protecting against what threats?
The CLR code access security system is intended to protect resources of user data from the threat of hostile partially trusted code running on the user's machine.
The relationship between reflection, access control and security in the CLR is therefore complicated. Briefly and not entirely accurately, the rules are these:
full trust means full trust. Fully trusted code can access every single bit of memory in the process. That includes private fields.
The ability to reflect on privates in partial trust is controlled by a permission; if it is not granted then partial trust code may not do reflection on privates.
See http://blogs.msdn.com/b/shawnfa/archive/2006/09/29/777047.aspx for details.
See
http://blogs.msdn.com/b/shawnfa/archive/2006/10/05/using-lightweight-codegen-from-partial-trust.aspx
for details
The executive summary is: you can lock partially trusted code down sufficiently that it is not able to use reflection to look at private stuff. You cannot lock down full trust code; that's why it's called "full trust". If you want to restrict it then don't trust it.
So: does making a field private protect it from the threat of low trust code attempting to read it, and thereby steal user's data? Yes. Does it protect it from the threat of high trust code reading it? No. If the code is both trusted by the user and hostile to the user then the user has a big problem. They should not have trusted that code.
Note that for example, making a field private does not protect a secret in your code from a user who has your code and is hostile to you. The security system protects good users from evil code. It doesn't protect good code from evil users. If you want to make something private to keep it from a user then you are on a fool's errand. If you want to make it private to keep a secret from evil hackers who have lured the user into running hostile low-trust code then that is a good technique.