15

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?

AJJ
  • 2,938
  • 4
  • 14
  • 14
  • 2
    If you are creating some API, you need to anticipate the functionality that a caller may need. Thus you'll need to put more thought into your access modifiers. It depends on who is using the code that you're writing. – user2023861 Mar 29 '16 at 19:39
  • Possible duplicate of [Do ALL your variables need to be declared private?](https://softwareengineering.stackexchange.com/questions/57491/do-all-your-variables-need-to-be-declared-private) – gnat Sep 21 '18 at 17:00

3 Answers3

14

Short answer: Yes

Longer answer:

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.

Community
  • 1
Ben Cottrell
  • 11,656
  • 4
  • 30
  • 41
  • So if I were to try to summarize what you're saying back to you (to see if I understand), it is a good idea to instead think of the public-facing interface first (i.e. how is this class actually being used by the outside to begin with?) and then make everything else private? – AJJ Mar 29 '16 at 20:10
  • 1
    @ArukaJ A good approach is to write code that will use your classes before you build the implementation. This can be a bit of a chicken or egg problem until you start writing unit tests first. – JimmyJames Mar 29 '16 at 20:20
  • 1
    @ArukaJ Broadly yes; which at first may seem more difficult to do, although as JimmyJames mentions, it feels a lot more intuitive when you're writing unit tests. It may involve a slightly different mindset, but the goal is to think more carefully about what your class represents, and what your inputs/outputs look like - overall that's just a much more "OO" way of thinking about design; more likely to result in neatly encapsulated classes with high cohesion. – Ben Cottrell Mar 29 '16 at 22:37
  • I'm leery of using unit tests to design your class, because unit tests aren't the ones who will really be using it. However, they are definitely better than nothing in thinking how the class will be used. – user949300 Mar 30 '16 at 00:37
9

"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.

gnasher729
  • 42,090
  • 4
  • 59
  • 119
  • 1
    Let's say you have a class that you don't intend to subclass at this time (and *might* never need to) and a method that if you *were* to subclass your class, would be useful/required to/by the subclass. Would you make that method `private` or `protected`? – lfk Jul 05 '18 at 00:52
  • Should be the accepted answer, make everything private at first sounds like I don't want to think/design. – NingW May 23 '19 at 17:52
  • @Ifk good question to consider, but you should have provided an answer and an explanation so others reading your comment could learn something from it. – rmutalik Apr 01 '23 at 10:40
1

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.

Chris Ghyzel
  • 21
  • 3