What is the point of setters and getters in java?

Question

Please forgive the length, but here are two programs, both the exact same, but one with and one without setters, getters, and constructors.

I've taken a basic C++ class before and don't remember any of these from it, and at the moment I'm not seeing the point of them, if anyone could explain them in lamen's terms I'd much appreciate it...at the moment they seem to be nothing more than space wasters to make my code look longer, but the teacher says they are important (and so far that's it).

Thanks in advance! And now here's the code: Mileage.java:

package gasMileage;

import java.util.Scanner; //program uses class Scanner

public class Mileage 
{
    public int restart;
    public double miles, gallons, totalMiles, totalGallons, milesPerGallon;
    public Mileage(int newRestart, double newMiles, double newGallons, 
             double newTotalMiles, double newTotalGallons, double newMilesPerGallon)
    {
     setRestart(newRestart);
     setMiles(newMiles);
     setGallons(newGallons);
     setTotalMiles(newTotalMiles);
     setTotalGallons(newTotalGallons);
     setMilesPerGallon(newMilesPerGallon);
    }
    public void setRestart(int newRestart)
    {
     restart = newRestart;
    }
    public int getRestart()
    {
     return restart;
    }
    public void setMiles(double newMiles)
    {
     miles = newMiles;
    }
    public double getMiles()
    {
     return miles;
    }
    public void setGallons(double newGallons)
    {
     gallons = newGallons;
    }
    public double getGallons()
    {
     return gallons;
    }
    public void setTotalMiles(double newTotalMiles)
    {
     totalMiles = newTotalMiles;
    }
    public double getTotalMiles()
    {
     return totalMiles;
    }
    public void setTotalGallons(double newTotalGallons)
    {
     totalGallons = newTotalGallons;
    }
    public double getTotalGallons()
    {
     return totalGallons;
    }
    public void setMilesPerGallon(double newMilesPerGallon)
    {
     milesPerGallon = newMilesPerGallon;
    }
    public double getMilesPerGallon()
    {
     return milesPerGallon;
    }
    public void calculateMileage()
    {
     Scanner input = new Scanner(System.in);
     while(restart == 1)
     {
      System.out.print("Please input number of miles you drove: ");
      miles = input.nextDouble();
      totalMiles = totalMiles + miles;
      System.out.print("Please input number of gallons you used: ");
      gallons = input.nextDouble();
      totalGallons = totalGallons + gallons;
      milesPerGallon = miles / gallons;
      System.out.printf("Your mileage is %.2f MPG.\n", milesPerGallon);
      System.out.print("Would you like to try again? 1 for yes, 2 for no: ");
      restart = input.nextInt();
     }
     milesPerGallon = totalMiles / totalGallons;
     System.out.printf("Your total mileage for these trips is: %.2f.\nYour total gas consumed on these trips was: %.2f.\n", totalMiles, totalGallons);
     System.out.printf("Your total mileage for these trips is: %.2f MPG", milesPerGallon);
    }
}

Mileagetest.java:

package gasMileage;

public class Mileagetest 
{
    public static void main(String[] args) 
    {
     Mileage myMileage = new Mileage(1,0,0,0,0,0);
     myMileage.calculateMileage();
    }
}

And now for the one without setters and getters:

Testmileage.java:

package gasMileage;

import java.util.Scanner;

public class Testmileage 
{
    int restart = 1;
    double miles = 0, milesTotal = 0, gas = 0, gasTotal = 0, mpg = 0;
    Scanner input = new Scanner(System.in);
    public void testCalculate()
    {
     while(restart == 1)
     {
      System.out.print("Please input miles: ");
      miles = input.nextDouble();
      milesTotal = milesTotal + miles;
      System.out.print("Please input gas: ");
      gas = input.nextDouble();
      gasTotal = gasTotal + gas;
      mpg = miles/gas;
      System.out.printf("MPG: %.2f", mpg);
      System.out.print("\nContinue? 1 = yes, 2 = no: ");
      restart = input.nextInt();
     }
      mpg = milesTotal / gasTotal;
      System.out.printf("Total Miles: %.2f\nTotal Gallons: %.2f\nTotal MPG: %.2f\n", milesTotal, gasTotal, mpg);
    }
}

Testmileagetest.java:

package gasMileage;

public class Testmileagetest 
{

    /**
     * @param args
     */
    public static void main(String[] args) 
    {
     Testmileage test = new Testmileage();
     test.testCalculate();
    }

}

Thanks again!

Answer 1

The point of accessor methods ie. getters and setters is to provide encapsulation AKA information hiding. It's one of the basic principles of object oriented programming.

Accessor methods

Information hiding/encapsulation

Answer 2

The point is that a class should not allow direct access to its fields, because this is implementation-specific. You may want to change the class later in order to use another data storage, but keep the class the same for its "users", or you may want to create an interface which cannot include fields either.

Have a look at the Wikipedia article on the subject.

Answer 3

The point of getters and setters, regardless of language, is to hide the underlying variable. This allows you to add verification logic when attempting to set a value - for example, if you had a field for a birth date, you might only want to allow setting that field to some time in the past. This cannot be enforced if the field is publicly accessible and modifyable - you need the getters and setters.

Even if you don't need any verification yet, you might need it in the future. Writing the getters and setters now means the interface is kept consistent, so existing code won't break when you change it.

Answer 4

The idea is that if your client classes call get/set functions, you can change what they do later and the callers are insulated. If you have a public variable, and I access it directly, there is no way for you to add behavior later when it is accessed or set.

Even in your simple example, you could take more advantage of it.

Instead of using:

milesPerGallon = miles / gallons;

in calculateMileage()

You could change setMiles() and setGallons() to update milesPerGallon when they were called. Then, remove setMilesPerGallon() to indicate that it's a read-only property.

Answer 5

They provide a public interface for your class, and some measure of encapsulation. Consider how you would access public data without getters and setters.

Mileage m = new Mileage();
m.miles = 5.0;
m.gallons = 10.0;
...

Now if you decide you want to add some validation to your class, you have to change your code everywhere that the fields were directly accessed. If you just use getters and setters from the start (only where they are needed) you can avoid that effort, and only change your code in one place.

Answer 6

Fast forward a few months. Maybe your teacher asks you to implement a remote version of the Milage class. Maybe as a web service, maybe something else.

Without the getter/setters, you'd have to change every code everywhere that acccesses a Milage, with the getter/setters you pretty much(in a perfect world atleast) just have to change the creation of a Milage type.

Answer 7

Using getters and setters gives you the flexibility to change the implementation later. You might not think you need that, but sometimes you do. For example, you might want to use the Proxy pattern to lazy load an object that is expensive to use:

class ExpensiveObject {
    private int foo;

    public ExpensiveObject() {
       // Does something that takes a long time.
    }

    public int getFoo() { return foo; }
    public void setFoo(int i) { foo = i; }
}

class ExpensiveObjectProxy extends ExpensiveObject {
    private ExpensiveObject realObject;

    public ExpensiveObjectProxy() { ; }

    protected void Load() {
       if ( realObject == null ) realObject = new ExpensiveObject();
    }

    public int getFoo() { Load(); return realObject.getFoo(); }
    public void setFoo(int i) { Load(); realObject.setFoo(i); }
}

class Main {
    public static void main( string[] args ) {
         // This takes no time, since ExpensiveOjbect is not constructed yet.
         ExpensiveObject myObj = new ExpensiveObjectProxy();

         // ExpensiveObject is actually constructed here, when you first use it.
         int i = myObj.getFoo();
    }
}

Where this often comes to play is when you have objects mapped to databases through an ORM. You only load the stuff you need, then go back to the database to load the rest if/when it is actually used.

Answer 8

The answer in one word is interfaces.

Interfaces allow for methods, not fields, so the established convention is to have getX and setX methods for this purpose.

(And interfaces is the way to decouple functionality from implementation in Java)

Answer 9

Encapsulation

Accessor methods ("setters and getters") attempt to hide the details about how the data in an object is stored. In practice, they are a glorified means to store and retrieve data in a non-object-oriented fashion. Accessors do not effectively encapsulate anything in that there is little practical difference between the following two pieces of code:

Person bob = new Person();
Colour hair = bob.getHairColour();
hair.setRed( 255 );

And this:

Person bob = new Person();
Colour hair = bob.hairColour;
hair.red = 255;

Both code snippets expose the idea that a Person is tightly coupled to Hair. This tight coupling then reveals itself throughout the code base, resulting in brittle software. That is, it becomes difficult to change how a Person's hair is stored.

Instead:

Person bob = new Person();
bob.setHairColour( Colour.RED );

This follows the premise of "tell, don't ask." In other words, objects should be instructed (by other objects) to perform a specific task. This is the whole point of object-oriented programming. And very few people seem to get it.

The difference between the two scenarios is this:

• In the first situation, Bob had no control over what colour his hair would become. Great for a hair stylist with a penchant for redheads, not so great for Bob who despises that colour.
• In the second situation, Bob has complete control over what colour his hair will become because no other object in the system is allowed to change that colour without Bob's permission.

Another way to avoid this problem is to return a copy of Bob's hair colour (as a new instance), which is no longer coupled to Bob. I find that to be an inelegant solution because it means there is behaviour that another class desires, using a Person's hair, that is no longer associated with the Person itself. That reduces the ability to reuse code, which leads to duplicated code.

Hiding Data Types

In Java, which cannot have two method signatures that differ only by return type, it really does not hide the underlying data type used by the object. You will seldom, if ever, see the following:

public class Person {
  private long hColour = 1024;

  public Colour getHairColour() {
    return new Colour( hColour & 255, hColour << 8 & 255, hColour << 16 & 255 );
  }
}

Typically, the individual variables have their data type exposed verbatim by use of the corresponding accessor, and requires refactoring to change it:

public class Person {
  private long hColour= 1024;

  public long getHairColour() {
    return hColour;
  }

  /** Cannot exist in Java: compile error. */
  public Colour getHairColour() {
    return new Colour( hColour & 255, hColour << 8 & 255, hColour<< 16 & 255 );
  }
}

While it provides a level of abstraction, it is a thin veil that does nothing for loose coupling.

Tell, Don't Ask

For more information on this approach, read Tell, Don't Ask.

Answer 10

Your example is extreme to the point of absurdity. Yes, all those getters and setters bloat the code and add no value in that case. But the underlying idea of encapsulation is meant for larger systems composed of many interacting components, not for small, self-contained programs.

Characteristics of useful, sensible uses of getters and setters:

• A class that is used by many other classes (hiding implementation details makes it easier for the clients)
• Getters and setters only for fields for which they're actually needed - as few as possible, most fields should be private and used only within their class
• Very few setters in general: mutable fields make it much harder to keep track of the program's state than read-only fields
• Getters and setters that actually do something besides accessing a fied, e.g. setters that throw exceptions for invalid values or update a "last modified" timestamp, or a getter that computes a value on the fly rather than relying on an underlying field

Answer 11

The other answers generally give a good idea of some reasons for using getters and setters, but I want to give a somewhat complete example of why they are useful.

Let's take, for example, a file (ignoring the existence of a File class in Java). This File class has a field for storing the type of the file (.pdf, .exe, .txt, etc)... we'll ignore everything else.

Initially you decide to store it as a String with no getters and setters:

public class File {
   // ...
   public String type;
   // ...
}

Here are some issues with not using getters and setters.

No control over how the field is set:

Any clients of your class can do what they want with it:

public void doSomething(File file) {
   // ...
   file.type = "this definitely isn't a normal file type";
   // ...
}

You decide later that you probably do not want them to do that... but since they have direct access to the field in your class, you have no way of preventing it.

Inability to easily change internal representation:

Later still, you decide that you want to store the file type as an instance of an interface called FileType, allowing you to associate some behavior with different file types. However, many clients of your class are already retrieving and setting file types as Strings. So you'd have an issue there... you'd break a lot of code (even code in other projects that you can't fix yourself, if it's a library) if you just changed the field from a String to a FileType.

How Getters and Setters solve this

Now imagine that you had instead made the type field private and created

public String getType() {
   return this.type;
}

public void setType(String type) {
   this.type = type;
}

Control over setting the property:

Now, when you want to implement a requirement that only certain strings are valid file types and prevent other strings, you could just write:

public void setType(String type) {
   if(!isValidType(type)) {
       throw new IllegalArgumentException("Invalid file type: " + type);
   }
   this.type = type;
}

private boolean isValidType(String type) {
   // logic here
}

Ability to easily change internal representation:

Changing the String representation of the type is relatively easy. Imagine you have an enum ValidFileType which implements FileType and contains the valid types of files.

You could easily change the internal representation of the file type in the class like this:

public class File {
   // ...
   private FileType type;
   // ...
   public String getType() {
      return type.toString();
   }

   public void setType(String type) {
      FileType newType = ValidFileType.valueOf(type);

      if(newType == null) {
         throw new IllegalArgumentException("Invalid file type: " + type);
      }

      this.type = newType;
   }
}

Since clients of the class have been calling getType() and setType() anyway, nothing changes from their perspective. Only the internals of the class changed, not the interface that other classes are using.

Answer 12

Getters and Setters Getters and Setters allow you to build useful shortcuts for accessing and mutating data within an object. Generally, this can be seen as an alternative to having two functions with an object that are used to get and set a value, like so: { getValue: function(){ return this._value; }, setValue: function(val){ this._value = val; } } The obvious advantage to writing JavaScript in this manner is that you can use it obscure values that you don't want the user to directly access. A final result looking something like the following (using a closure to store the value of a newly constructed Field): function Field(val){ var value = val;

this.getValue = function(){
    return value;
};

this.setValue = function(val){
    value = val;
};

}

Adding Setter and Getter Methods To make the state of the managed bean accessible, you need to add setter and getter methods for that state. The createSalutation method calls the bean’sgreet method, and the getSalutation method retrieves the result. Once the setter and getter methods have been added, the bean is complete. The final code looks like this: package greetings;

import javax.inject.Inject; import javax.enterprise.context.RequestScoped; import javax.inject.Named;

@Named @RequestScoped public class Printer {

@Inject @Informal Greeting greeting;

private String name;
private String salutation;

public void createSalutation() {
    this.salutation = greeting.greet(name);
}

public String getSalutation() {
    return salutation;
}
public String setName(String name) {
   this.name = name;
}

public String getName() {
   return name;
}

}