Private method creep 1
Refactoring has been a buzz around the software industry for quite some time now. No matter what Editor you use, there are some kind of refactoring tools that will do all the dirty work for you.
The most common refactoring is probably the extract method. With a couple of clicks, a shiny new private method is generated with all the extracted code inside of it. This is where the problem creeps in. There's nothing wrong with private methods, but when you have a hand full of them it usually means that your class is carrying too much responsibilities. It should be split out into multiple classes.
Michael Feather recently had a post titled The Deep Synergy Between Testability and Good Design. In the post, Michael mentioned that the need to test private methods should prompt a redesign by breaking out the private methods into a new class. With the ease of the refactoring tools, redesign doesn't always come to mind since it does everything for you. Michael recognized that private methods are actually public interface of another class. As Michael said in his post, by removing private methods you are improving your design and increasing the testability of your code. Isn't that what we are all after?
Yeah, that was a good post. I whole-heartedly agree. Particularly if you are not satisfied that your private methods are being sufficiently tested through the public interface tests, then you have a problem and your private methods do too much.
One individual commented (in the original post, by Larry) that his configuration is in a private method and pulling it out into a class would violate information sharing. I don't think that's true at all. You are simply pulling the functionality of reading your configuration out into another class, but you still have your private instance of that class that is yours alone, and therefore your configuration is still hidden from clients. That's very different from exposing your configuration to the world via a public method.