Hide your class details with Java Access Modifiers – J027

DeegeU Java Course

The “Hide your class details with Java Access Modifiers” is part of a larger free online class called “Free Java Course Online”. You can find more information about this class on “Free Java Course Online” syllabus.

Transcript – Hide your class details with Java Access Modifiers

When I was in high school, I ate at Taco Bell so many times the manager offered me a job. I said no. It wasn’t that I was against working there, I just did not want to know how my burritos were made. I just wanted the completed burrito!

We want to do this with our classes as well. A few methods should be exposed to the rest of the application, but the details on how the class works should stay hidden behind the curtain. In this lesson, I’m going to teach you how to hide you class implementation details.

This lesson is about encapsulation, information hiding, and access modifiers. Encapsulation is one of the three big concepts when talking about object oriented programming. So you’ll want to make sure you understand this lesson. As always, if you have a question, ask in the comments below or on DeegeU.com.

Encapsulation is grouping functions and variables into a class. Pretty simple. You have to do this to make a class in Java. Encapsulation also lets us do something called information hiding. Information hiding is pretty much what it sounds like. We are hiding parts of our class from the view of other classes.

If you’re making a game, and you need to move an enemy ship towards the player, you just want to call moveTowardsPlayer(). Now that method might call other methods to check for obstacles, find a path, determine if it has enough fuel, and so on.

You should not expect someone using your class to know they have to call several methods in order to move the bad guy. They might forget to call one method, and then suddenly you’ve got a bug where the bad guys are moving through planets. Not cool. Or they might skip calling the methods, and just set the positional values to what they want.

We need a way to enforce what methods are called, and what methods have the rights to change values. Information hiding lets us hide the details, and control how our classes are used. This is more than a best practice. It’s a must practice!

When we define methods or attributes, we can specify how they are accessed using an access modifier. Access modifiers are placed before the thing you want to control. The access modifier keywords are public, private, package, and protected. You can put the access modifier before classes, methods, and attributes.

You’ve already seen public in action with the main method. public means anyone can see it. That’s what you’d want from a main method. It says, “Hey! Start using this class here”.

Everything inside a class should always start as private. That’s a best practice. Private means only this class can see the method or attribute. We denote that with a minus sign in our class boxes. You can’t make a private outer class. That would be an invisible class, that nothing can use. Private is the most restrictive access modifier. You can always relax the access later, but it’s very difficult to rewrite code to make a method or attribute more restrictive. So always start with private.

The opposite of private is public. That should be your last option when choosing access modifiers. Public means any other class can call your class’s methods, and if it’s an attribute, any other class can change the value. There are very few instances where you would want to make an attribute public. That’s a free-for-all.

Public methods are the API to your classes, meaning that’s what you want people to use when using your class. That’s the moveTowardsPlayer() method in our space game. We denote public methods and attributes with a plus sign in our class boxes. Classes are usually public, because you want classes to see each other. Usually.

When you don’t want a class to be accessed outside of a package, you can define your class as package scope. There’s no keyword for package scope, you just leave it blank. There’s no symbol in our boxes for package scope either. We saw Java packages in the last lesson. Package scope says this class, method or attribute can only be seen by other classes inside the package. Classes belonging to other packages cannot see anything marked for a different package scope.

The last access modifier is a bit tricky to understand at this point. It’s called protected. There’s a concept called inheritance where classes can be related to each other, and protected says the classes must be related to see the method or attribute. Or in the same package. Package scope is more restrictive than protected. You cannot create a protected outer class. We’ll cover this one more in later lessons. We use the pound or hashtag symbol to denote protected methods and attributes.

So I said everything should start as private. We’ll cover that more in the next lesson. See you there.