The Difference Between Private and Public in Java

The Difference Between Private and Public in Java Featured Image

As I was writing my first semester of teaching reflection, I got the idea to kick off a series of student questions called Coding Tangents. In this series, I’ll be tackling student questions with clear, easy-to-follow explanations that demystify common programming language syntax. In particular, I’d like to tackle the difference between public and private in Java today.

Table of Contents

The Problem Students Encounter

Often times when we teach Java, we’re stuck leaving a lot of the syntax as a mechanical process. In other words, we tell students that keywords like publicstatic, and private will be explained to them later. In the meantime, they just have to trust that we will actually explain those concepts later.

One of these pieces of syntax that almost always gets left for a later discussion is private vs. public. These keywords are known as access modifiers, and we’ll dig into them in this article.

But first, let’s take a look at an example of some code that is almost certain to raise some questions about access modifiers:

public class HelloWorld {
  public static void main(String[] args) {
    System.out.println("Hello, World!");
  }
}

In order to teach Java, we’re often stuck introducing the language using these horrible five lines of code. After all, this is the bare minimum required to get a Java program running.

As a result, we’re often forced to tell students something along the lines of:

Don’t worry about the outer four lines. Just place whatever code you want to execute in the middle block.

Computer Sciences Professors Everywhere

Of course, this line of reasoning leaves a lot to be desired if you’re a new student. For example, what do any of those four outer lines do? What’s public? How about static, String[], or System.out.println?

 Luckily, I’m hear to cover the access modifier part today.

The Explanation Students Desire

At this point, let’s talk about access modifiers at a high level.

Access Modifier Overview

In Java, access modifiers are a way to help us from stepping on our own feet. In general, they’re used to set some level of access to a class, method, or variable.

For example, if we want to model something from the real world (say a car), there are certain aspects of that object we probably don’t want to expose to the public (say individual control over the wiper blades). Perhaps under the hood, the wipers are individually controlled, but we’ve built our system such that the switch given to the user has encapsulated that behavior. In other words, both wipers move together as expected. 

Had we chosen to expose individual control over each wiper, we may find that many users accidentally break the wiper functionality. After all, if the wipers aren’t perfectly synced, they may smash into each other.

That’s the high level idea behind access modifiers. We use them to expose or hide certain functionality to improve the overall user experience. 

Misconceptions

At this point, a lot of students will start thinking that access modifiers are some way to make your code more secure from hackers. While this is true to some extent, that’s not really their purpose. Instead, we tend to use access modifiers for encapsulation. 

Encapsulation is the art of reducing a complex state down to a set of exposed behaviors. If I were to ask you to throw a ball, you certainly wouldn’t start by requesting a set of matrix transformations for the rotation of your arm. You’d just throw the ball. That’s the idea behind encapsulation (and abstraction). 

In this example, we can use access modifiers to specify which behaviors are exposed. For example, we’d probably want to allow users to access the throw command but maybe not the rotateArm or pickUpBall commands. 

Now that we’ve tackled some of the misconceptions, let’s get into the syntax.

Keywords

In Java, there are actually four access modifiers: publicprivatepackage (default), and protected. Each keyword offers a level of code access given by the following table:

publicprivatepackageprotected
Same ClassTTTT
Different Class in Same PackageTFTT
Sub-Class in Same PackageTFTT
Different Class in Different PackageTFFF
Sub-Class in Different PackageTFFT

In other words, we can rank the keywords in order of least accessibility:

  1. private
  2. package (default)
  3. protected
  4. public

For the duration of this tutorial, I will not be exploring the package or protected keywords as they’re a bit more nuanced, but I figured they were important to mention.

Classifying Actions as Public or Private

Using the ball throwing example from before, let’s try to figure out which access modifier would be appropriate in various situations:

  • public
    • throw
    • catch
    • toss
    • pitch
  • private
    • rotateArm
    • translateVertices
    • pickUpBall
    • calculateVolume

Notice how all the high level actions are public and the lower level actions are private. That’s because we don’t necessarily want to expose the lower level actions to the public. But, why not? Let’s take a look at another example.

Let’s say that the high level functions rely on some underlying state of the system. For instance, throwing a ball relies on knowing information like the strength of gravity and the properties of the ball. If someone were somehow able to access the lower level actions, they could potentially manipulate these basic assumptions of the world.

What would happen if we were able to access actions like setGravity or setBall? How would our high level actions like throw or catch change?

Using the setGravity command, I could tell you that gravity is actually twice as strong as you think it is before telling you to throw the ball. At that point, you’d update your model of the world before significantly increasing the force of your throw to accommodate for the change in gravity. However, in reality, gravity hasn’t actually changed, so instead you overthrow the ball.

This scenario is often what happens when we expose lower level functionalities that don’t trigger automatic updates of dependent properties. In many cases, systems are very complicated, and changing one underlying parameter results in the failure of the system. As a result, we try to encapsulate functionality to cover all our bases. 

Hello World Revisited

Now that we’ve seen some high level explanations, let’s dig back into our Hello World example.

public class HelloWorld {
  public static void main(String[] args) {
    System.out.println("Hello, World!");
  }
}

Here we can see that we use the public keyword twice: once for the class and again for the main method. In other words, we’ve chosen to expose both the HelloWorld class and the main method to the public. 

To make things a little more interesting, let’s wrap the print in its own private method:

public class HelloWorld {
  public static void main(String[] args) {
    printHelloWorld();
  }

  private static void printHelloWorld() {
    System.out.println("Hello, World!"); 
  }
}

If we try to run this solution, we’ll notice that the behavior hasn’t changed at all. That’s because private methods can be used in their own class. Outside HelloWorld, however, no one knows printHelloWorld() even exists. In fact, we could try to call the method directly from another class in the same folder, and we’d find ourselves with an error:

public class CallPrivateMethod {
  public static void main(String[] args) {
    HelloWorld.printHelloWorld();  // ERROR
  }
}

As we can see, we’ve hidden away the printing functionality, so that it can only be used by the HelloWorld class. If for some reason we made the printHelloWorld() method public, we could run it just fine.

Open Forum

Hopefully this helps you understand the difference between the private and public keywords, and why we use them. If not, I’m open to any feedback and questions you may have. Feel free to use the comments below to start a bit of a dialogue. And if this helped you out at all, share it with your friends. I always appreciate the support!

Advertisements

Leave a Comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.