0

Reflection breaks the Encapsulation principle. Can we protect encapsulation principle being break from reflection? Is there any API through which we can protect encapsulation from reflection ?

thSoft
  • 21,755
  • 5
  • 88
  • 103
sjeev
  • 43
  • 5
  • 1
    I think you need to reword this to be much more specific, possibly with an example. "Encapsulation principle" is just way too broad and general. – ajb Aug 05 '13 at 16:13
  • 3
    You are looking for obfuscation....something that you should only do if it is REALLY needed..which in most cases it is not...here is a SO on the topic: http://stackoverflow.com/questions/2537568/best-java-obfuscator – Justin Pihony Aug 05 '13 at 16:13
  • You mean forbidding `setAccessible()`? – tkroman Aug 05 '13 at 16:14
  • 3
    See http://stackoverflow.com/questions/1796055/is-reflection-breaking-the-encapsulation-principle – Mihai8 Aug 05 '13 at 16:15
  • You can probably disable reflection with a custom SecurityManager – assylias Aug 05 '13 at 16:15
  • @assylias: Can probably disable reflection with a custom SecurityManager. Can I get some sample code like how we can disable it? – sjeev Aug 05 '13 at 16:22
  • @sjeev see for example: http://stackoverflow.com/questions/762459/how-to-disable-java-security-manager – assylias Aug 05 '13 at 16:25
  • As the chosen answer for the question user1929959 referenced mentions, reflection is not the only way one can break encapsulation. If the user really wants to access the `private` fields of an object they can serialize the object and read the serialized data directly (this will only work on `Serializable` object and will still protect `private transient` fields, but I am sure there are way to access those without directly using reflection as well). – SamYonnou Aug 05 '13 at 16:55
  • This is controlled by SecurityManager. As I understand it you'd need to create your own subclass of it and reject reflection requests. – Hot Licks Aug 05 '13 at 17:02

2 Answers2

1

Technically, yes. A quick search on SO gives an example of preventing Reflection: https://stackoverflow.com/a/770672/2372767. However saying,

Reflection breaks the Encapsulation principle...

implies a misunderstanding of the principle. The point of Encapsulation is not to protect your code from malicious other code, or protect your implementation, or even create some level of security.

When you make an interface (class, module, object, etc.) with public and private methods, you're actually making two interfaces: one that is easy to use, and one that isn't. Essentially, when you make something private, what you're really saying is "this is part of the messy, complicated details of getting something done, and it may be dangerous to call this directly."

The point I want to drive home is this: your private interface is still an interface, and should be treated with the same care as your public methods. While you should never encourage another programmer to use private members, you don't know when someone else is going to need to use one of those messy, complicated steps.

As other users have mentioned, there are other ways to get a private class members. Reflection is an easy-to-use API to accomplish the same task.

Community
  • 1
  • 1
SlightlyCuban
  • 3,185
  • 1
  • 20
  • 31
  • There are folks who get their shorts in a knot if you, eg, have a public field in a class, saying that "breaks encapsulation". The "encapsulation principle" is ill-defined at best (though there are an awful lot of "authorities" who claim to know what it means). – Hot Licks Aug 05 '13 at 17:04
  • @HotLicks IMO, that would only break encapsulation if there is some internal state a public field would expose. In reality there isn't much of a difference between a public field and a simple getter & setter (although the latter pattern is much easier to maintain). – SlightlyCuban Aug 05 '13 at 17:38
  • But reflection exposes internal state. And (in what I believe is contrary to the original intent) reflection is being used rather routinely to monkey with state that is not "public". – Hot Licks Aug 05 '13 at 18:19
  • @HotLicks half my point is reflection exposes internals in a non-obvious way; it doesn't destroy the message "this interface is dangerous to use". The other half is you cannot ultimately control what someone else will do to your code, you can only instruct them to the best way to use it. In what I believe is contrary to the original intent, private is routinely used as a temporary workbench and not maintained as well as the public interface. – SlightlyCuban Aug 05 '13 at 19:13
0

On of many definitions of encapsulations says this A language mechanism for restricting access to some of the object's components. You use this mechanism while you design your application. It was never a task for it to secure the application anyway. Therefore you may not use this concept as a secure mechanism and you for sure may not claim that Reflection brakes it. Only developer may brake the reflection by leaving something not encapsulated.

Damian Leszczyński - Vash
  • 30,365
  • 9
  • 60
  • 95
  • OTOH, if every Tom, Dick, and Henry is using reflections to monkey with the innards of "encapsulated" classes that does indeed "break encapsulation" -- it's no different from making the internal members public. Reflection is an abomination, albeit a necessary one. – Hot Licks Aug 05 '13 at 17:08
  • @HotLicks, "Guns do not kill people, people does". Reflection is a good thing, when used correctly. Like atom power, you can create a nuke or power plant. You can think that is an abomination but from my point of view is something really good that allow you enlarge your application modularity. – Damian Leszczyński - Vash Aug 05 '13 at 17:20
  • Except how is reflection different from making everything public, other than to add a layer of inefficient obfuscation? – Hot Licks Aug 05 '13 at 17:22
  • Your question take one problem and compare it with another. There for logically there is not a good answer to it. Having everything public will for sure make a non trivial system very hard to maintain. As base rule is that everything what is public might be used by someone else. From the other hand when you use reflection to get into the class interior and change the scope you take the risk of the consequences a well. If you think about reflection as a tool to read the hidden things, you do not use it correctly. Thant's it. – Damian Leszczyński - Vash Aug 05 '13 at 17:33
  • Except that reflection is being used rather routinely, and it does not readily discriminate between public and private data. – Hot Licks Aug 05 '13 at 18:34