Our discussion of classes and objects is integral to us using object-oriented programming. Object-oriented programming stands on four pillars: abstraction, encapsulation, inheritance, and polymorphism.
Encapsulation is the bundling of related data and behaviors that operate on that data, usually with restricted access to internal, non-public data and behaviors. In object-oriented programming, classes and objects allow us to encapsulate, or isolate, data and behavior to only the parts of our program to which they are relevant. Restricting access allows us to expose only that data and behavior that we want others to be able to use.
Let’s take a look at this by developing a new class called Student
.
Student
Class¶We previously defined a field as a variable, or piece of data, that
belongs to a class. For our Student
class, let’s think about the
data that is typically associated with a student (in the sense of a high
school or college student). There are a lot of possibilities, but here
are the most important:
In order to declare these fields within our class, we’ll need to determine the best data type for each. A field may be of any primitive or object type. In this case, the following types will work best:
String
int
int
double
Let’s put these inside of a class. While they may be declared anywhere within a class, fields should always be declared at the top of the class. When we’re ready to add methods, we’ll add them below the fields.
1 2 3 4 5 6 7 8 | public class Student {
String name;
int studentId;
int numberOfCredits;
double gpa;
}
|
Like variables within a method, fields may be initialized when they are
declared. For example, we could provide default values for
numberOfCredits
and gpa
(default values for name
and
studentId
don’t make sense since they should be different for each
student).
int numberOfCredits = 0;
double gpa = 0.0;
Fields are also referred to as instance variables, since they belong to an instance of a class.
As declared, our four fields are package-private, which means that they can be read or changed by any code within the same package. As a rule-of-thumb, fields should always be private unless you have a very, very, very good reason to not make them so. So, let’s make our fields private.
1 2 3 4 5 6 7 8 | public class Student {
private String name;
private int studentId;
private int numberOfCredits = 0;
private double gpa = 0.0;
}
|
In order to provide access to private fields, getter and setter methods are used. Getters and setters do what you might guess: get and set a given field. If we make the getter and/or setter method for a given property public, then others will be able to access or modify the field in that way.
Here is a getter/setter pair for name
(you can imagine how the
others would be written).
1 2 3 4 5 6 7 | public String getName() {
return name;
}
public void setName(String aName) {
name = aName;
}
|
Note
Prefixing a parameter that is intended to set an instance variable with
a
is a relatively common convention, and one that we’ll adopt to
avoid shadowing and having to use this
in our setters. You can think
of the a
as denoting the “argument” version of the variable.
An astute question to ask at this point would be, “Why make the fields private if you’re just going to allow people to get and set them anyway!?” Great question. There are lots of reasons to use getters and setters to control access. Here are just a few:
As an example of reason 2, let’s take a short detour to look at a
Temperature
class. A valid temperature can only be so low (“absolute
zero”), so we wouldn’t want to allow somebody to set an invalid value.
In setFahrenheit
we print out if an invalid value is
provided.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 | public class Temperature {
private double fahrenheit;
public double getFahrenheit() {
return fahrenheit;
}
public void setFahrenheit(double aFahrenheit) {
double absoluteZeroFahrenheit = -459.67;
if (aFahrenheit < absoluteZeroFahrenheit) {
System.out.println("Value is below absolute zero");
}
fahrenheit = aFahrenheit;
}
}
|
Note
When writing getters and setters, the convention for a field named
field
is to name them getField
and setField
. This is more
than just a convention, as some libraries you use will expect names to
be of this format, and won’t work as desired if you don’t follow the
convention.
A property in Java is a characteristic that users can set. Our
Student
class had properties name
, studentId
,
numberOfCredits
, and gpa
, while our Temperature
class had
only one property, fahrenheit
.
Most often, properties will be fields that have public setters, though
they need not have a corresponding field. Let’s look at an example of a
property that doesn’t directly correspond to a field. If we wanted to
add a celsius
property to the Temperature
class above, we might
do it as follows:
1 2 3 4 5 6 7 8 | public double getCelsius() {
return (fahrenheit - 32) * 5.0 / 9.0;
}
public void setCelsius(double celsius) {
double fahrenheit = celsius * 9.0 / 5.0 + 32;
setFahrenheit(fahrenheit);
}
|
Since there’s a link between fahrenheit
and celsius
, we want to make
sure that when one is updated, so is the other. In this case, we only
store one field value (fahrenheit
) and make the appropriate
calculation when getting or setting the celsius
property.
Note
There are slight variations among Java developers when it comes to colloquial usage of the term property. People will sometimes define the term in a slightly more specific or narrow way, to mean a private field with public getters and setters.
Using properties, getters/setters, and fields, we can encapsulate the information we need in our student class.
Question
What is a method that is used to give a private field a value?