There is no other computing book that I regard as high as Martin Fowler's Refactoring - Improving the Design of Existing Code. I am therefore thrilled to have seen refactorings take a major leap into mainstream development during the last couple of years. For the uninitiated, refactoring deals with how to make computer code beautiful, maintainable and easier to read, without changing functionality.
One of the most common refactorings there are is Encapsulate Field, which tells us to make a member variable private and wrap it in public set and get methods. The rationale behind this is to separate data from behavior and allowing us to change the implementation without having to change all callers.
I hate it.
It's not that the refactoring is bad per se, it's just that it's being misused right and left. Why would you want to bloat your code with trivial get/set accessors instead of just making the member public? Also, most modern languages have constructs for making a public member read-only, if you only want to allow get, without set.
If you want to implement a non-trivial accessor function, it is very likely that you would want the accessor to be a method instead, whose name will better describe the implementation.
While the argument that it would be easier to change the implementation in one place rather than in several is true, I'd much better hold that refactoring/code bloat off for now, and run my IDE's "Find references" and make the necessary refactorings later if need be.
Anyway, if you want to rename the member variable, you will have to rename the accessor, as well as all callees, or you will have an bad code smell.
Do yourself a favor, hold off the Encapsulate Field next time and just DTSTTCPW! My guesstimate says that it is only preferable to use this refactoring in 5% of the cases where you have a member variable you want to expose.
The only real reason where I constantly see the benefit of designing members encapsulated are in published interfaces which you don't want to or cannot modify.