When do you write a private method, versus protected? [closed]

Answer 1

I typically will start at the lowest level. If you're unsure make it private. Then as needed you can make things protected or public.

The idea being it is not a breaking change to go from private to protected but it could be a breaking change to go the other way.

Answer 2

public and protected methods form the 'interface' to your object, public for developers using (delegating to) your class, and protected for developers wishing to extend the functionality of your object by subclassing it.

Note that it's not necessary to provide protected methods, even if your class will be subclassed.

Both public and protected interfaces need careful thought, especially if this is an API to be used by developers outside your control, since changes to the interface can break programs that make assumptions about how the existing interface works.

private methods are purely for the the author of the object, and may be refactored, changed and deleted at will.

I would go for private by default, and if you find you need to expose more methods, have a careful think about how they will be used - especially if they are virtual–what happens if they are replaced completely with an arbitrary alternative function by another developer–will your class still work? Then design some appropriate protected which are useful for developers subclassing your object (if necessary), rather than exposing existing functions.

Answer 3

In other words, how I can know in advance that a client programmer would never ever need to override a method?

If you don't know assume they will need to. If that's fine by you (ie, if you think they should be able to) then use protected; otherwise use private.

Answer 4

I typically just make everything private and refactor when I need to call it from a base class.

Except when I feel lazy and do everything protected that isn't definitely dangerous.

Answer 5

I always make all methods private as default. This is to keep the interface clean and easy to maintain.

It is much harder to change or hide an already visible method than to make a private method more visible. At least if you need to be compatible with existing client code.

Answer 6

Private members are used to encapsulate the inner workings of your class. Use them to hold data that only you want to be able to access. For example, let's say you have a field called _name and a getter/setter named GetName()/SetName(name). Maybe you want to do some syntax checking on name before you allow the SetName to succeed, else you throw an exception. By making _name private, you ensure that this syntax checking will occur before any changes to name can occur (unless you yourself change _name in your own class, in your own code). By making it protected, you're saying to any potential future inheritor of your class, "go ahead and monkey with my field."

In general, protected is used sparingly and only in specialized cases. For example, you might have a protected constructor that exposes some additional construction functionality to child classes.