CODEWITHSUNDEEP
javacoding-style
Sinan
Sinan

Reputation: 463

good software practice - get and set methods

as you can see the class below declares 2 private instance variables and 2 get & 2 set methods associated with each private member to allow for manipulation and validation of them.

My question is: which is better to use in the constructor deceleration, the instance variables directly as shown in the snippet below or to use the set methods associated with them and also which is promote good software practices to use in the toString method, the instance variables or their getter methods?

thank you for your time.

public Class Employee {

  private String firstName;
  private String lastName;

  public Employee (String first, String last)
  {
    firstName = first;
    lastName = last;
  }//end of constructor

  public void setFirstName(String first)
  {
    firstName = first;
  }//end of method setFirstName

  public String getFirstName()
  {
    return firstName;
  }

  public void setLastName(String last)
  {
    lastName = last;
  }//end of method setLastName

  public String getLastName()
  {
    return lastName;
  }//end of method getLastName

  public String toString()
  {
    return String.format ("%s: %s %s\n", "Employee Name: ", firstName, lastName);
  }//end of method toString

}//end of class Employee

Upvotes: 2

Views: 1102

Answers (5)

Attila
Attila

Reputation: 28762

If you expect your class to be extended (and the getter/setter overridden), it is best to use the methods instead of the variables.

NOTE: I'm not sure what happens exactly in the constructor, you are probably better off setting the variable directly.

You can mark the getter/setter as final and then you don't have to worry about overrides. Still a good practice to use those methods instead of direct access as you can put breakpoints or debug statements there more easily

Upvotes: 1

claesv
claesv

Reputation: 2113

In general I tend to avoid calling non-static methods from the constructor (since the object isn't fully initialized at that stage). If the setter methods only sets a field to the parameter value, like above, I'd just set it in the constructor (i.e. not call the setter). If the setter is more complex, I'd try to factor out the logic to a static helper method, and use it both from the constructor and the setter methods. Something like:

 int field_;     

 Constructor(int initialValue) {
     field_ = helper(initialValue);
 }

 public void setField(int value) {
     field_ = helper(value);
 }

 // not really complex, but avoid duplication of logic
 private static int helper(int value) {
     return 2*value;
 }

Upvotes: 1

Yazan Al-Alul
Yazan Al-Alul

Reputation: 482

I would use the setter. Sometimes you have extra code in the setters. For example, the setter for a list might also hook the list's Changed event, and by not using the setter, you will not capture the Changed event.

Upvotes: 0

scibuff
scibuff

Reputation: 13755

Rule #1, always limit the access to the least necessary, i.e. unless you explicitly need to change the values of the first/last names, make the object immutable (constructor with parameters, no setters only getters)

Upvotes: 2

Brian Agnew
Brian Agnew

Reputation: 272317

I tend to favour initialisation via construction. By using this method and providing appropriate checks (compilation time via final and runtime via null checks or similar) you can ensure your object is properly and completely instantiated.

Using the final keyword on your fields will make the compiler check that you've assigned a value to that field upon construction. It does mean that field is immutable, but it's surprising how often you require that.

I would be careful with providing getters for everything. If you're continually providing and using getters, that suggests that you're pulling data out of your object and manipulating it outside that object. Remember - a key principle of OO is getting objects to do things for you, rather than asking them for data and doing it yourself.

Upvotes: 5

Related Questions