Private vs Protected - Visibility Good-Practice Concern?

Question

I've been searching and I know the theoretic difference. - **public** - Any class/function may access the method/property. - **protected** - Only this class and any subclasses may access the method/property. - **private** - Only this class may access the method/property. It won't even be inherited.That's all fine and well, the question is, what's the **practical** difference between them? When would you use `private` and when would you use `protected`? Is there a standard or acceptable good practice over this one?Up until now, to retain the concept of inheritance and polymorphism, I use `public` for anything that should be accessed from the outside (like constructors and main class functionality), and `protected` for internal methods (logic, helper methods etc). Am I on the right track?(Note that this question is for me, but also for future reference as I haven't seen a question like this one SO).

Answer 1

As you say, 'public' is only for those methods you want the outside word able to invoke. (There is never a valid reason that I'm aware of for making a class variable public...that's what getters and setters are for.)

As for 'protected' vs 'private', private should be the default. Obviously, if you anticipate never needing to inherit from a given class, there's no reason to make anything protected. If there is, I personally hesitate to make class variables protected. Instead, assuming they aren't already public, I make the getters/setters protected for those items that may be needed by inherited classes. As for methods, again any that are not already public are made protected IF there is a need for them in child classes. This would be in two cases: 1) the method needs to be executed as-is, so make protected instead of duplicating the code or 2) the child class has an identically named method that does part of the work but invokes the parent class' version to do the rest, again to avoid code duplication.