java - Dosen't Reflection API break the very purpose of Data encapsulation? -

very came across reflection api , surprise can access , alter private variables.i tried following code

import java.lang.reflect.field;  public class someclass{     private string name = "john"; }  public class test{     public static void main(string args[]) throws exception {         someclass myclass = new someclass();          field fs = myclass.getclass().getdeclaredfield("name");         fs.setaccessible(true);          system.out.println("variable " + fs.getname() + " , value "                 + fs.get(myclass));          fs.set(myclass, "sam");         system.out.println("variable " + fs.getname() + " , value "                 + fs.get(myclass));     } } 

and got following output.

variable name , value john variable name , value sam 

we java object oriented language , it's main features data encapsulation, inheritance, polymorphism.. etc. isn't reflection api changing purpose of data encapsulation? why have use reflection api? read in sites can used testing purpose according me modules tested , can done using junit test cases. can explain why have such hack?

isn't reflection api changing purpose of data encapsulation?

yes , no.

• yes, uses of reflection api can break data encapsulation.
• no, not uses of reflection api do break data encapsulation. indeed, wise programmer breaks encapsulation via reflection api when there reason so.
• no, reflection api not change purpose of data encapsulation. purpose of data encapsulation remains same ... if wilfully breaks it.

why have use reflection api?

there many uses of reflection do not break encapsulation; e.g. using reflection find out super types class has, annotations has, members has, invoke accessible methods , constructors, read , update accessible fields , on.

and there situations is acceptable (to varying degrees) use encapsulation breaking varieties of reflection:

• you might need inside encapsulated type (e.g. access / modify private fields) simplest way (or way) implement unit tests.

• some forms of dependency injection (aka ioc), serialization , persistence entail accessing and/or updating private fields.

• very occasionally, need break encapsulation work around bug in class cannot fix.

i read in sites can used testing purpose according me modules tested , can done using junit test cases. can explain why have such hack?

that depends on design of class. class designed testable either testable without need access "private" state, or expose state (e.g. protected getters) allow testing. if class doesn't this, junit test may need use reflection inside abstraction.

this not desirable (imo), if writing unit tests class wrote, , can't "tweak" apis improve testability, may have choose between using reflection or not testing @ all.

---

the bottom line data encapsulation ideal strive achieve (in java), there situations pragmatically correct thing break or ignore it.

note not oo languages support strong data encapsulation java does. example, python , javascript both unarguably oo languages, yet both make easy 1 class access , modify state of objects of class ... or change other classes behaviour. strong data abstraction not central everyone's view of object-oriented means.