In a discussion outside of this blog a developer suggested to me that encapsulation was kind of pointless in light of today’s more practiced methodologies. He said that we hide data behind a class so that if the data changed it would not affect anyone using the class. However, because he works on an agile development team with an iterative development cycle that lives and breathes changes, encapsulation was of little concern to him. His application is self-contained at his company so he is aware of all the client code. A simple change to a class’ interface and the compiler will point out all the places affected.

I explained that I too am in an environment where I have control over all clients of the object model so the affects of a simple data change can be easily handled. The encapsulation misunderstanding here is that exposing data is not the problem, or at least not the direct problem.  Writing logic against exposed data is what leads to duplicated logic, difficult and incomplete tests, and a fragile design. I have mentioned previously in this blog that at the end of the day my business objects do expose their data, more than would be ideal for sure. The solutions required to prevent exposure are often just not that practical. What is of the utmost importance is that the correct reasons are understood for not abusing the exposed data so any abuse is less likely to happen. The less this is understood and enforced, the more dangerous exposing object data is. 

If you are on a team of OO developers very keen to this understanding and code reviews or other practices are in place, then you could expose all your objects’ data without much fear of fragility. On the other hand, if you are surrounded by developers of varying OO-awareness then more ought to be done to hide object data so logic is not accidentally misplaced.