setters and getters

  • (2 Pages)
  • +
  • 1
  • 2

16 Replies - 1660 Views - Last Post: 06 October 2011 - 09:17 PM Rate Topic: -----

#1 bhojnp  Icon User is offline

  • New D.I.C Head

Reputation: 0
  • View blog
  • Posts: 17
  • Joined: 18-September 11

setters and getters

Posted 06 October 2011 - 08:20 AM

In the context of classes, why setters and getters are often omitted? any idea ??
Is This A Good Question/Topic? 0
  • +

Replies To: setters and getters

#2 Fuzzyness  Icon User is offline

  • Comp Sci Student
  • member icon

Reputation: 669
  • View blog
  • Posts: 2,438
  • Joined: 06-March 09

Re: setters and getters

Posted 06 October 2011 - 08:29 AM

It all depends on the situation. Sometimes in certain classes you may not want to be able to alternate any of the variables, but you may need to get them to see what they are.
Was This Post Helpful? 0
  • +
  • -

#3 bhojnp  Icon User is offline

  • New D.I.C Head

Reputation: 0
  • View blog
  • Posts: 17
  • Joined: 18-September 11

Re: setters and getters

Posted 06 October 2011 - 08:40 AM

any more ideas ????
Was This Post Helpful? 0
  • +
  • -

#4 Fuzzyness  Icon User is offline

  • Comp Sci Student
  • member icon

Reputation: 669
  • View blog
  • Posts: 2,438
  • Joined: 06-March 09

Re: setters and getters

Posted 06 October 2011 - 08:44 AM

It really all depends on the class. Normally if you create a Class for a Custom object, you would need alteast a getter. So really getters often ARE needed not omitted. Perhaps there is an situation you are wondering about specifically?
Was This Post Helpful? 0
  • +
  • -

#5 Ryano121  Icon User is offline

  • D.I.C Lover
  • member icon

Reputation: 1363
  • View blog
  • Posts: 3,002
  • Joined: 30-January 11

Re: setters and getters

Posted 06 October 2011 - 08:53 AM

There is also the concept of data hiding where the enclosing members of an object are not visible to any other object (a.k.a. no setters/getter). This means that other objects don't have access to the implementation of another object, they just use the object to complete a task without knowing what it uses to do so.

However there is also the case as Fuzzyness said, where some classes need to have setters and getters to allow other objects to use or modify its members. Again it depends on what you are working on. Some objects shouldn't have getters/setters as they should keep their implementation private. Others however are the exact opposite.
Was This Post Helpful? 0
  • +
  • -

#6 smohd  Icon User is offline

  • Critical Section
  • member icon


Reputation: 1820
  • View blog
  • Posts: 4,627
  • Joined: 14-March 10

Re: setters and getters

Posted 06 October 2011 - 08:56 AM

May be if you know what getter and setter do, you may no where are used and where are not. These are methods used to make our private instance variables accessed outside the class they belong, mostly using the object of the class. Getter used to get the value of the variable and setter used to set the variable. With some restriction put into them, we can manage the change made to our needs accordingly. For example if we dont need our variable to have less then zero value, we can use our getter to restrict that.

Also in the part of encapsulation, after making our variables private, we may need although to get or set their values outside the class. this work will be done by those methods.
Was This Post Helpful? 0
  • +
  • -

#7 immeraufdemhund  Icon User is offline

  • D.I.C Regular

Reputation: 79
  • View blog
  • Posts: 495
  • Joined: 29-March 10

Re: setters and getters

Posted 06 October 2011 - 06:38 PM

consider two different scenarios when it comes to data hiding and when not too. The first is focused on a "car" class. You are working on a group project for say a racing game. You are responsible for the fuel data. Now you could go about it a few different ways. You first consider just giving getters and setters for the gallons (or liters) of fuel in your car. But then realize that a few differnt people are going to use your class potentially at the same time. For sake of argument lets call it the pit crew programmer and the gauge cluster programmer. The pit crew programmer sets a timer up that adds x amount of fuel into your tank. and the guage person is getting your fuel and your tank capacity at around the same time. Well That could potentially have you guys getting and setting info at the exact same time and cause a error, or a delay of sorts. The solution would be to justd give them there own function to give info needed for the car class to do what it needs something like car.getFuelGuage(); or car.addFuel(double quantity). Now neither party has to syncronize with each other your class would do that for them.

But consider the other side of the coin. You are making a contact information program. You have a class person. Well it would be silly to hide your data because to fill out a contact page you need getters. If a person changes address or changes name, or number etc then you need setters.

so like everyone is saying it all depends on the data and your situation. I feel it important that if you have to do math on something and you are calling it from another class then don't make getters setters just make a nice function that does what you really want (mpg, fuel left %) but if you just need a quick look into data and don't need to modify it any then just make getters/setters.
Was This Post Helpful? 0
  • +
  • -

#8 pbl  Icon User is offline

  • There is nothing you can't do with a JTable
  • member icon

Reputation: 8347
  • View blog
  • Posts: 31,912
  • Joined: 06-March 08

Re: setters and getters

Posted 06 October 2011 - 06:49 PM

class Employee {
    static private int employeeNumber = 0;

    private int employeeId;

    // constructor
    Employee() {
       employeeId = ++employeeNumber;
    }


employeeNumber does not need neither a getter neither a setter
employeeId only needs a getter
Was This Post Helpful? 1
  • +
  • -

#9 jon.kiparsky  Icon User is online

  • Pancakes!
  • member icon


Reputation: 8028
  • View blog
  • Posts: 13,740
  • Joined: 19-March 11

Re: setters and getters

Posted 06 October 2011 - 06:59 PM

The question is not whether getters and setters are "omitted", the question is, why do you put them there in the first place? You only want to write the code that you actually need, and you never want code that some ignorant IDE stuffs in there by default.

So, if you're designing a class and there's a reason for another class to be able to read its data (why?) or to set its data (double why?) then you put the method in. But first you think about what it is you're modelling, and whether this is actually the right thing to do. It's often important for support classes to have "set" methods - ie, a GUI element might have a "setEnabled" and a "getEnabled" and that would be reasonable - but for your actual workhorse classes there are very few real-world situations that are modelled by "setSuchAndSuch".

Never write a getter or a setter by reflex, and always think twice, three times, and then think again before you do. It's usually the wrong thing to do.
Was This Post Helpful? 2
  • +
  • -

#10 pbl  Icon User is offline

  • There is nothing you can't do with a JTable
  • member icon

Reputation: 8347
  • View blog
  • Posts: 31,912
  • Joined: 06-March 08

Re: setters and getters

Posted 06 October 2011 - 07:31 PM

Ohhh Jon, you are walking on eggs here
All these students, the first things they are teached to do are:
- put all your instance variables private
- provide a getter and a setter for each of them

We all know that in real life this is not what happens but you are opening a can of worms here, really not a good idea
Was This Post Helpful? 0
  • +
  • -

#11 jon.kiparsky  Icon User is online

  • Pancakes!
  • member icon


Reputation: 8028
  • View blog
  • Posts: 13,740
  • Joined: 19-March 11

Re: setters and getters

Posted 06 October 2011 - 07:37 PM

Well, they have to live in the real world some time. I'm not here to lie to anyone.

Once in a while I get to be the bad cop. :)

getQ and setQ are good for one purpose: they're simple methods that you can write and understand easily. So it's good for a student to write them in their first classes. But once you know how to write them, they've done 90% of their work, and after that you'll write real code.

I guess it's like writing your sorts and your lists: step one is writing them once, so you understand them. This makes you a better programmer. Step two is knowing why you don't write them again. This makes you a much better programmer. You shouldn't skip either of those steps, but if you have to skip one, skip the first and not the second. :)
Was This Post Helpful? 0
  • +
  • -

#12 fromTheSprawl  Icon User is offline

  • Monomania
  • member icon

Reputation: 513
  • View blog
  • Posts: 2,063
  • Joined: 28-December 10

Re: setters and getters

Posted 06 October 2011 - 07:52 PM

On the book I'm reading right now it is said that getters and setters are used to making fine - grained classes and making classes with none or a minimal amount of them makes them coarse - grained. Fine - grained because all the methods for accessing fields are available to you, coarse - grained because you're only given a couple of methods that return something you need by using the fields inside that class. The author even supported the coarse - grained classes. He presented a valid point, you should just make methods that do the stuff you need to be done and return only the information you need.

He also said why would you do this:

int sum = product.getX() + product.getY();



When you can just do:
int sum = product.sum();

//Meanwhile, inside sum

public int sum(){
return this.x + this.y;
}



That's a little example and can be smashed by anyone with reasoning, but use it in other context and you will see that it makes sense to just get the things you want.

This post has been edited by fromTheSprawl: 06 October 2011 - 07:52 PM

Was This Post Helpful? 0
  • +
  • -

#13 pbl  Icon User is offline

  • There is nothing you can't do with a JTable
  • member icon

Reputation: 8347
  • View blog
  • Posts: 31,912
  • Joined: 06-March 08

Re: setters and getters

Posted 06 October 2011 - 08:01 PM

Real life:
we have, at my office, servers performing 85,000 transactions/second peak time... and we expect a 30% increase in the operations required to be performd in the next 6 months.
At $ 250,000 a CPU how can you justify to higher management ?
"We will respect OO Java rules and use getter/setter for all operations, and I will perform 60,000 operations per second" or "let's access directly the variables, and we will perform 85,000 operations per second"

Real life and academical practices are quite different
Was This Post Helpful? 0
  • +
  • -

#14 immeraufdemhund  Icon User is offline

  • D.I.C Regular

Reputation: 79
  • View blog
  • Posts: 495
  • Joined: 29-March 10

Re: setters and getters

Posted 06 October 2011 - 08:22 PM

WHOA! it can slow it down that much.. that is crazy
Was This Post Helpful? 1
  • +
  • -

#15 jon.kiparsky  Icon User is online

  • Pancakes!
  • member icon


Reputation: 8028
  • View blog
  • Posts: 13,740
  • Joined: 19-March 11

Re: setters and getters

Posted 06 October 2011 - 08:31 PM

If you happen to be programming in a resource crunch, yes, that would affect your decisions. But if you're working in a resource crunch, and unsafe coding techniques are acceptable, and you're working on only one platform, running the code server side, as it sounds, why use Java at all? Wouldn't C be a better choice for what you're describing?

If you're not working in a resource crunch, and the real cost is developer time, not CPU time, then your main concern is to make sure that it's difficult to break your code. Writing tightly-coupled highly-dependent classes might get you a performance boost with excellent and very careful programmers, but I don't recommend it as a best practice for novices, because it makes it very easy to break the code and very difficult to be sure that you haven't broken something. Even with the best programmers, when you entangle all of your classes you're increasing the risk of strange bugs that are difficult to track, and that become exponentially more difficult as the codebase grows. Strange and difficult bugs, in most situations, cost a lot more to find and to fix than the cycles they save.
Was This Post Helpful? 0
  • +
  • -

  • (2 Pages)
  • +
  • 1
  • 2