DevOps Zone is brought to you in partnership with:

Yet another developer. Java, C#, C++. Aiming for Scala. Rado is a DZone MVB and is not an employee of DZone and has posted 11 posts at DZone. You can read more from them at their website. View Full User Profile

Reflection Against OOP Principles

05.31.2013
| 7807 views |
  • submit to reddit

What is so cool about the possibility to access private class members from outside? Everyone keeps asking you during job interviews what are the basic rules of object oriented programming. This is a mandatory knowledge to pass at least the first round. Encapsulation is one of them. Of course, of course.

When you finally get a job and start coding, you realize that many popular frameworks for ORM break this rule easily. Usually it is used in some form of data mapping (for instance @Autowired in Spring). Don't worry. The frameworks are wiser than some ancient principles. Just sit back and relax.

What's wrong with that?

  1. Strange things are happening in your code and you have no idea what and when is changing value in your private int. How can it be even changed if there is no assignment to it? Where would you put a breakpoint to debug it? 
  2. You would like to use such class in your unit test and would like to set the value explicitly. Hmm, you can't. There's no setter because nobody needed it before.
  3. If there is some form of annotation like @Autowired it's easier to find out what's going on, but there are tools that don't need such annotation. What would you think when you look at a class with private members only and without any getters and setters? You know that the class is used and that the application works. What? How?
Reflection is very powerful, but I think that there are better ways of using it.

Published at DZone with permission of Rado Buranský, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)