Is it fair to say that it is good practice to default everything to
private up front when coding something?
And then only upgrade it to
protected if a subclass needs it, or
public if another class needs it?
Software Engineering Stack Exchange is a question and answer site for professionals, academics, and students working within the systems development life cycle. It only takes a minute to sign up.Sign up to join this community
Short answer: Yes
Yes, but that shouldn't be interpreted as a suggestion to start by writing your classes with everything private; that approach implies class design by focusing on the implementation detail before you've settled on an interface.
One of the most important aspects to consider when designing a class is how it will be used; which involves thinking about your public methods before you start thinking about private/implementation details.
Furthermore, that approach is usually missing out on chances to ask yourself "How would I write a unit test for this class?" - which is an important question to ask even if you aren't actually writing unit tests. (Related: "What are the design principles that promote testable code?" )
So, once you have defined the public interface, then it is a good idea to default the rest to private because most of that will typically be gritty implementation detail which is of no concern to anything outside of the class.
"And then only upgrade it to protected if a subclass needs it, or public if another class needs it?"
That's the wrong approach. At design time, you should know what public access you want to give. Usually you give public access because that's the whole purpose of your class. And you give protected access because you want subclasses to access things. And you use private for things that are nobody else's business.
Now if someone needs access to things they can't access, then you should think really hard about that need. They shouldn't need that access, or your design is wrong. Maybe your design is wrong, and something isn't public that should be public, so you change that. But if your design is right, then there is something wrong with the need, so you fix that instead of damaging your design.
The key to understanding this aspect of Object Oriented programming is the concept of data encapsulation. The idea is to make a class easier to understand by hiding its implementation details. This is called data hiding. Thus, we only want to expose (make public) those functions which are necessary to use the class. These functions are the interface to the class.
Think of an interface like the wheel of a car. You decide what direction the car goes by turning the wheel, but underneath the covers there are rotary valves, hydraulics, pulleys changing the rotation of your wheels, but you don't need be a mechanical engineer to drive a car.
So the answer to your question is yes. You want to hide as many details about a class from other classes as possible. Understanding when something should be public, private, or protected is easy to learn but hard to master.