public, private, protected, or package - I don't know... do you?

[Rooks Forgenal]

Say I have some code like:

Node Root = (the root of tree);
public Node search(Object obj){
return getNode(Root, obj);
}
 

and it accesses code like this:

private static Node getNode(Node Root, Object obj){
//... returns the Node containing the object you were searching for
}
 

Do I make the second bit of code public, private, protected, or package? I don't believe anyone would want to access that particular method but maybe. Say they wanted to run the search from a custom 'root'. I don't know, I am just making that up. I am pretty sure they can't break anything if they ran it directly, so what do you think?

[Sebastian Janisch]

You always want to hide most of the implementation of a class and only expose the necessary parts to the outside world.

If private static Node getNode(Node Root, Object obj) is only a helper function for the use of other functions in the same class, the private modifier is appropriate.

If you really think the function on it's own makes sense to expose to other classes, feel free to mark it public.

[Jesper de Jong]

Indeed, keeping the public API of your classes as small as possible is an important design principle. This has to do with loose coupling. If all classes in your application knew all the details of all other classes, you'd have a big mess of spaghetti code, which is hard to understand and maintain.

So, a good rule of thumb is: Make member variables and methods private, unless you have a good reason to make them more accessible.

[Campbell Ritchie]

Jesper Young wrote: . . . spaghetti code . . .

That's a nice article, particularly the pictures.

[Jesper de Jong]

The Wikipedia article doesn't really go into spaghetti code in object oriented programming, but I just learned that that's called spaghetti with meatballs... (hmm, it's lunchtime here in half an hour...).