When should methods be made private? [closed]

Answer 1

Everything not included in the class's interface should (must, really) be private. If you're not sure what the class's interface is (i.e., you're not http://www.artima.com/lejava/articles/designprinciples.html>programming to interfaces or those interfaces aren't yet fully defined, start with everything private and make things public, protected, package-private, etc. as needed.

But think carefully! Once something is accessible to other code, there's a dependency between that code and this class and refactoring is constrained. Rule of thumb: Expose only those methods that define the abstraction, not how it's implemented.

Answer 2

The rule is that a method should be made provided unless it is needed. One of the main reasons for this is that in a future release of an API etc., you can always make a private function public, but you can almost never make a previous public function private without breaking existing code.

Answer 3

If the class is for internal use within your organization, i.e. you are not distributing this as a general-use library, then I heartily agree that you should make as much private or protected as possible. If later you discover that some other class needs access to a private function, fine, at that point change it to public. It's not hard to do.

My only caveat would be if this is something you are "publishing", where others who do not have a direct line to get changes made will be using it. Then you need to carefully think out a complete API.

But failing that, just write the code you need. Don't write functions that you think you might use someday.

Answer 4

1. 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)

2. 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.

Answer 5

I always follow this: "Design for tomorrow, code for today."

If today you need only one public method then keep only one public method.

Answer 6

simple rules:

1. If you are not looking to expose it outside of the class that is using it, make it PRIVATE.

2. If you are looking to expose it inside the same assembly to other classes but not outside the assembly, make it INTERNAL (C#) / Friend (VB.NET).

3. If you are looking to expose the functionality outside the assembly to everyone, make it PUBLIC