When to use private methods?

Question

I understand what public/protected/private accessors mean in Java or PHP for instance. However, when would you choose whether to make a method private?

Imagine I have a class that handles configuration strings - they must conform to a particular regular expression, and if so, further logic is performed to make sure the strings are valid.

I currently have this code in a private method in a Configuration class. This class accepts configuration strings and then returns values to client code after validating the strings.

However, I want to unit test the validation code, so perhaps it should be in another class. I typically don't do this though unless I know that the code will be reused. If it will only be used by a single class as in this case, I normally just make the method private.

So, my question is - what design rules should inform a programmer that a particular method should be private compared to being moved into its own class?

Answer 1

The Single Responsibility Principle is what I usually have in mind. Also, consider if you really need the validation in this class or if it does not have anything to do with it (perhaps the validation should not be handled in the domain logic but another layer above it). Private methods, as you probably already know should not be tested in unit tests so if you really need to test this kind of functionality perhaps you should put it in its own validation class, responsible for validation only and then test it.

Answer 2

Then if function i use only local in object and i don't want show to other objects her because i can use her in future and make mistake and this will do some mess in my code i don't must thinking a lot to think what function i must use and what i can't use.

I using private method everywhere and doing some simple and short public methods to get/set data to my objects then i don't have mess in my code.

Answer 3

You should use private method when you are refactoring your code in class. for example if you have some peace of code that repeats more than one in code. you should to make extract method refactoring. look at more refactoring methods refactor

Answer 4

Implement you validation logic as a strategy as in the strategy pattern. This way you can not only unit test them separately but also replace the validation logic later on easily if and when required.

So make a separate Validator class which implements IValidator interface. Then compose your Configuration class with the appropriate Validator by injecting it as a dependency in Configuration's constructor.

Answer 5

Leave the private validation methods in the same class, and make the unit test class a friend of that class (in C++, at least--in Java, put the unit test in the same package).

Answer 6

Read more about SOLID design principles SOLID

Answer 7

If no special requirement, keep members as private. I think its main purpose is to make better "encapsulation" and maintenance.

For example, you define a Car.class with different steer mode. Car(.class) has a member maxSpeed, which is setted by a setter: Car.maxSpeedSet(int mode). then the user cannot directly know or change the value for maxSpeed, except by changing its mode through the method.

In this way, users don't need to care or write a function about how maxSpeed is got from the mode. And when you need to change the function: maxSpeed = f(mode), you don't have to change it everywhere the Car is used. you just change the method maxSpeedSett(). perfect for encapsulation and maintenance, isn't it?

if a member is only: x= a, 'public' seems good enough but make sure you will not change the method of assigning in the future, especially when there are too many dependance on the class.