Quote Originally Posted by kempofighter
One reason that it might make sense to define the accessor is for testability. Since private data can't be accessed by test drivers, it might make sense to have them so that test drivers can always test the internal state of the class without having to mess with the friend mechanism. So you might want to think about how you are planning to unit test your code, if at all. I can't think of any other reason to provide accessors for all attributes, by default. Don't define them just for the sake of defining them. Tools can be set to not generate them.
While that is certianly one way to address the testability issue. I will typically take it a step further to minimize "abuse", IF you utilize Factory type patterns to support a DI architecture...

If you need access to provate data for testing putposes, implement a PROTECTED accessor with a specific name (e.g Get_XXX_4Test()). Then implement a derived class. By using a specialized factory, you transparently create your test instances where the test code can access the information in question, but there is no risk that the "production" code will be developed against the "Test" interface.

If you do NOT utilize a DI ready architecture, then creating an INDEPENDANT class which can contain a "mirror" of the state can help. In this pattern you simply ad one method that returns you a snapshot of the state (ie an instance of the INDEPPENDANT class).

In any case, the goal is always to expose the minimum amount of information that is absolutely required.