When should methods be made private?
The only rule I follow is to make as little as possible public.
Look at it this way. You can always make something public later on - it won't break any existing code. Trying to make something private that was public could well end up breaking a lot of existing code.
If someone wants more functionality from your class then they can make the request and you can expose what they need. Chances are that they'll want something that's subtly different to what you already have anyway so you'll need a new interface.
A helpful guidance technique to follow is to write an interface for your class before you start the implementation. Then when implementing, tell yourself that a method not in the interface should be private, or not in that class at all.
If you didn't know a method needed to be there when you were designing the contract of the class, it probably shouldn't be part of its public interface.
You should expose to the outside world only what the outside world really needs. It is often best to add functionality for consumers of the class when it is needed, rather than at first. These days the wisdom is to avoid pre-engineering. (see YAGNI)
It can certainly be acceptable to have public methods that are also used by other functionality within the class. However, this should be considered a minor bad smell. It might be an indication that your class is trying to do too many things.
My guess is to leave your classes as they are. Then, when these other, smaller methods are needed by the outside world, consider if you should separate your classes. If the purpose of each of these classes to to yield one report, then you should not expose these methods from this object. Instead, put "smaller" methods into a common helper class. That way they are available to the outside world without fundamentally changing the nature of your existing report classes. In short:
Don't just do it because you think it might be helpful later. If/When the additional functionality is needed, reconsider your overall design to accommodate the new requirements.
Public and private methods are very different beasts. Use caution before making a method public.
- Public methods must validate all of their parameters.
- They must be properly documented, including any exceptions that they might throw.
- All edge cases must be analyzed and delt with (in code or in documentation).
- Any requirements involving the order in which public methods are called must be documented or, preferably, removed.
- Object state requirements must also be documented and validated.
- Public methods must not change their signature or behavior in any way that may break an application when moving from one version to the next.
- Public methods may need to be designed with marshalling requirements. (Such as .Net's CLS restrictions.)
Private methods have none of these limitations.