Writing shy code is just a small start at preventing the introduction of bugs, but it really helps. Just as in the real world, good fences make good neighbor - as long as you don't peek through them.

http://www.computer.org/software/homepage/2003/s1const.htm
http://www.pragmaticprogrammer.com/ppllc/papers/1998_05.html

Other than that, there is also security risk if you show too much to other - http://www.indicthreads.com/articles/1096/returning_arrays_or_objects_java_security_problem_1.html

An example of why passing Map around is wrong and show solution of that example - http://antagonisticpleiotropy.blogspot.com/2008/01/hashmap-temptation.html 

Quoting from Getting Method in Beck’s 1997 Smalltalk Best Practice Patterns (emphasis his): “Here’s the real secret of writing good Getting Methods - make them private at first.  I cannot stress this enough. … There are cases where you will publish the existence of Getting Methods for use in the outside world.  You should make a conscious decision to do this after considering all the alternatives.  It is preferable to give an object more responsibility, rather than have it act like a data structure.”
Quoting from Setting Method: “Everything I said once about Getting Methods, I’d like to say twice about Setting Methods.  Setting Methods should be even more private.  It is one thing for another object to tear out your state, it is quite another for it to bash in a new state.”

http://tech.groups.yahoo.com/group/domaindrivendesign/message/5701

East: Clean and DRY, an example of why tell don't ask help - http://jamesladdcode.com/?p=294

But personally, I don't use tell-dont-ask. I do look to co-locate data and behavior, which often leads to similar results.  - http://martinfowler.com/bliki/TellDontAsk.html

Another discussion about getter and setter - http://www.yegor256.com/2014/09/16/getters-and-setters-are-evil.html