When should private methods be done?

Question

There are many times when I am not sure whether a particular method should be private or not. For example, now I am building a class that is responsible for creating a report. This class has a buildReport method and several methods that collect the necessary data for buildReport.

// single public method // uses a set of helper methods public buildReport() // helper methods private avgSurveyTime() private fetchVendors() private fetchSendCounts() private ... 

I am discussing whether these helper methods should be published. The only method that I really plan to call at the moment is buildReport() . However, it would be useful to get a list of providers with fetchVendors() , etc.

I see two schools of thought about this: you can always expose as little as possible. (In this case, many of my classes will have only one public method) OR you can expose anything that might be useful to the class user.

Is there a good rule to decide when methods should be public / private?

Answer 1

The only rule that I follow is to make as little public as possible.

Look at it like that. You can always do something public later - it will not break the existing code. An attempt to do something private that was public may well result in breaking a large amount of existing code.

If someone wants more functionality from your class, then they can make a request, and you can expose what they need. Most likely, they need something that is subtly different from what you already have, so you will need a new interface.

Answer 2

A useful maintenance technique is to write an interface for your class before you begin implementation. Then, when implementing, tell yourself that a method that is not contained in the interface must be private or not at all in this class.

If you did not know which method should be there when you were developing the class contract, it probably should not be part of its public interface.

Answer 3

• You should reveal to the outside world only what the outside world really needs. Often, it is best to add functionality for class users when necessary , rather than first. Today, the wisdom is to avoid pre-engineering. ( see YAGNI )

• Of course, it is permissible to have public methods that are also used by other functions within the class. However, this should be considered as minor bad smell . This may be a sign 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 whether you should separate your classes. If the goal of each of these classes is to give one report, you should not expose these methods from this object. Instead, put the "smaller" methods in a common helper class. Thus, they are accessible to the outside world without fundamentally changing the nature of your existing report classes. In short:

Do not just do it, because you think it may be useful later . If / When additional features are needed, change your overall design to meet new requirements.

Answer 4

Public and private methods are completely different animals. Be careful before publishing a method.

• Public methods must check all of their parameters.
• They must be properly documented, including any exceptions that they may throw.
• All edge cases should be analyzed and shared (in code or in documentation).
• Any requirements related to the order in which public methods are invoked should be documented or, preferably, deleted.
• Requirements for the condition of the facility should also be documented and verified.
• Public methods should not change their signature or behavior in any way that can break the application when switching from one version to another.
• Public methods may need to be developed taking into account sorting requirements. (Such as .Net CLS restrictions.)

Private methods do not have any of these limitations.

Answer 5

If this is not necessary outside the class in which it is currently located, make it private. If this is later, you can make it secure or public as needed.

If in doubt, make it private.

Answer 6

If the class is intended for internal use within your organization, i.e. you do not distribute it as a public library, then I sincerely agree that you should do as much as possible private or protected. If you later discover that some other class needs access to a private function, well, at that point, change it to a public one. It's not hard.

My only caveat would be if you are “posting” where others who do not have a direct line to make changes will use it. Then you need to carefully think through the full API.

But if it is not, just write the code you need. Do not write down functions that you think you will ever be able to use.

Answer 7

As a rule, you should disclose as little as possible and make everything possible private.

If you make a mistake and hide something that you should expose, not a problem, just make it publicly available. However, if you do something public, and then decide that it should be private, then you may have problems, because now the public method can be used by many other classes.

You can freely change the implementation of your personal methods without any external effects. If you have all public classes, this may not be possible because these methods can be used by something outside of your classes.

Answer 8

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

If today you need only one public method, save only one public method.

Answer 9

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

Answer 10

Everything that is not included in the class interface should (should, really) be closed. If you do not know what the class interface is (i.e. you are not http://www.artima.com/lejava/articles/designprinciples.html> programming for interfaces or these interfaces are not yet fully defined, start with all the private and make things public, secure, private packages, etc. as needed.

But think carefully! Once something is available for other code, there is a relationship between this code and this class and refactoring. Rule of thumb: expose only those methods that define abstraction, and not how they are implemented.

Answer 11

simple rules:

• If you do not want to open it outside the class that uses it, make it PRIVATE .

• If you want to expose it inside one assembly with other classes, but not outside the assembly, make it INTERNAL (C #) / Friend (VB.NET).

• If you want to expose functionality outside the assembly for everyone, do it PUBLIC

Answer 12

I am working on a system consisting mainly of two things: importing data from different sources and creating reports. The problem is that all this was developed by someone who does not have basic OO design skills. In the same “class”, they would have 'private' methods for reading data from the database, calling 'private' methods to verify the specified data, which is also called by another function 'private' 500-line duplicated more or less throughout the application which simply formats the specified data.

You should move away from private avgSurveyTime () private fetchVendors () private fetchSendCounts () from the actual class that handles the page layout.