• Post Reply Bookmark Topic Watch Topic
  • New Topic

Getters Setters  RSS feed

 
Rick Rod
Greenhorn
Posts: 10
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I am having a hard time understanding what the benefit is of Getters and Setters.
Dog a = new Dog()
a.Name = "big";

gives me the same result as
Dog a = new Dog()
a.setName("big");
a.getName();

so where is the benefit if I have to type more, and yes I am truly a novice(beginner)
 
Christophe Verré
Sheriff
Posts: 14691
16
Eclipse IDE Ubuntu VI Editor
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
First, you probably want your member variable (such as "name") to be private.
So you'll need some getter/setter to access it. a.name won't work.

Second, when you'll learn about JavaBeans and introspection, you'll understand how powerful if can be.
 
Jan Groth
Ranch Hand
Posts: 456
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
to put it a bit simpler: the main idea behind it is _encapsulation_

what you want is that only the dog-class cares about details of dogs. whoever works with dogs is not supposed to have (say: need) any knowledge about how dogs works.

okay, it might seem a bit trivial to protect a private string field with getters and setters. but what if some logic is required to set a valid name? say it's a login and you need to check if the name already exists somewhere else...

with protecting the name-field you are sure that nobody else can set the name from outside...

hope it helps,
jan
 
Dave Lenton
Ranch Hand
Posts: 1241
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Rick Rod:

Dog a = new Dog()
a.setName("big");
a.getName();


Also, you may wish to change the type of name to something other than String, for example, a StringBuffer. If other classes are calling your Dog class and directly accessing the field e.g. a.name="new name"; then you'll have to go through all of those other classes and change them to use StringBuffer instead of a String.

If, on the other hand, the other classes are using a setter, all you have to do is change the code in your setter to change the input value from a String to a StringBuffer. This means that when you change the fields in your Dog class, you only have to alter one bit of code rather then several bits of code in several classes.
 
Christophe Verré
Sheriff
Posts: 14691
16
Eclipse IDE Ubuntu VI Editor
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Dave,

I can't agree with your argument (sorry )

You'll still have to change getters. And changing a variable from classA to classB that have nothing in common will still need changes for setters.

I don't think that this is the purpose of getters/setters.
 
Jeff Albertson
Ranch Hand
Posts: 1780
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Satou kurinosuke:
I can't agree with your argument (sorry )

You'll still have to change getters.

Hmmm... I agree with Dave. Here's why:

The changes to the implementation from DogImpl1 --> DogImpl2 are not exposed to clients. I even emphasized that by introducing an interface. And that brings up another important point: in many important settings clients will be programming to the interface, not the implemenatation, because of techniques like dynamic proxies and cglib, so they have to rely on calling methods, not directly accessing fields.
[ February 09, 2006: Message edited by: Jeff Albertson ]
 
Stan James
(instanceof Sidekick)
Ranch Hand
Posts: 8791
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Don't automatically make getters for every field. Good objects do all the work on their data for you so you never have to (or get to) see the data. A neat way to remember this is "Tell, don't ask". Tell an object what you'd like it to do rather than asking it for its data.

This is rather advanced so don't worry if it doesn't make a lot of sense today, but any time you're about to get data from an object and do some work on the data, think about whether the other object couldn't do that work for you.

Here's a very simple example. I had a method that checked a bunch of "criteria" to decide whether or not to do something. It looked like:

I changed it to say

That eliminates two getter methods, makes the code I showed here simpler and more expressive, and encapsulates the matching rules in criteria so we can reuse them later.
[ February 09, 2006: Message edited by: Stan James ]
 
Ken Blair
Ranch Hand
Posts: 1078
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Stan James:
This is rather advanced so don't worry if it doesn't make a lot of sense today, but any time you're about to get data from an object and do some work on the data, think about whether the other object couldn't do that work for you.


And think about whether or not the data you're having to get should even be in that object and whether or not the object getting the data should need to get it. Often times when I see objects looking at each other's private data a lot I find a need for a third object becuase one or both of the other two have behavior they shouldn't.
 
Christophe Verré
Sheriff
Posts: 14691
16
Eclipse IDE Ubuntu VI Editor
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Jeff,
I do agree with what you say

But this is different from what Dave was relating to.
He was saying changing :
ClassA {
public void setName(String a);
}
To
ClassA {
public void setName(StringBuffer b);
}
 
Dave Lenton
Ranch Hand
Posts: 1241
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Satou kurinosuke:
Hi Jeff,
I do agree with what you say

But this is different from what Dave was relating to.
He was saying changing :
ClassA {
public void setName(String a);
}
To
ClassA {
public void setName(StringBuffer b);
}


Sorry, maybe I didn't phrase it well, but I did actually mean what Jeff said. The idea is that the signature of the setter remains the same, but it's inner workings (and their relations with the private fields of the class) remain hidden to whatever is calling the setter.

The idea is that setName always takes a String no matter what type name field has. The setter then has the responsibility of making the input match the field, rather then giving that responsibility to external classes.

Jeff summed it up nicely:
 
Niki Nono
Ranch Hand
Posts: 256
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
also maybe you want to store some specific format

ClassA {
public void setName(String a){
//do what you want with a or with someone else
}
 
Reed Spool
Greenhorn
Posts: 14
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Rick, I read your post and I had the same problem just a few weeks ago. Fortunately I had someone explain it to me very simply. I'll try to relay my understanding. I know you have a string here but i'm going to use numbers to explain the logic.
Let's say we have your dog class. Dogs have weight. Weight will never be below zero. your program might want to change the a Dog object's weight to equal -1, maybe because of an error, or because some punk user entered a weight that doesn't make sense. you could have your code just take that value and input it. or you could have a middle man <setter method> check that value for validity. I hope that was clear :-D
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!