Hi !
Featured games (90)
games approved by the League of Dukes
Games in Showcase (784)
Games in Android Showcase (234)
games submitted by our members
Games in WIP (858)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  Java getters/setters questionable usefulness.  (Read 5574 times)
0 Members and 1 Guest are viewing this topic.
Offline K.I.L.E.R

Senior Devvie

Java games rock!

« Posted 2004-03-11 10:03:04 »

Over the past couple of months of Java programming I've been cramped upon the use of getters and setters.

I have found that they do have a time and place however I've mostly found them to be extremely useless to variables you wish to externally modify.

public int a=5;

int b = a;
a = b*2;

////////////////////////////////////using get/set

private int a=5;

public int getA()
   return a;
public void setA(int value)
   a = value;

int b = A.getA();

In these cases, get/set methods are useless, yet people like my programming teacher says we must use get/set all the time.

I realise that the get method has it's uses for safety reasons so you don't accidentally overwrite the variable if you only want your variable to be read externally.

However, if you want to read/write to an external public variable, the use of getters and setters is useless, so why do people still do it?

Is it purely because that's the OOP approach of accessing public variables?

Is there a name for a "redneck" programmer?

Unemployed. Wink
Offline Herkules

Senior Devvie

Friendly fire isn't friendly!

« Reply #1 - Posted 2004-03-11 10:19:02 »

I have an opinion concerning that, and there have been lots of discussions.....

Mechanically wrapping a variable in a getter/setter is the same as making it public.

I use it as a mean to express some things: if I want to express that a variable is and has to be a piece of memory, I use a public variable.

This says: no computation takes place, no dependencies exist, no listeners will be notified, access will be quick, this is pure data! These are important informations!

OO gurus often talk of information hiding, but sometimes I have the impression they want to hide the important things from the persons who should know....

I admit the cases indicating a public member are rare, but they exist. And then I use them.

HARDCODE    --     DRTS/FlyingGuns/JPilot/JXInput  --    skype me: joerg.plewe
Offline princec

« JGO Spiffy Duke »

Medals: 1067
Projects: 3
Exp: 20 years

Eh? Who? What? ... Me?

« Reply #2 - Posted 2004-03-11 10:19:46 »

What he said.

Cas Smiley

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline K.I.L.E.R

Senior Devvie

Java games rock!

« Reply #3 - Posted 2004-03-11 10:30:17 »

That makes sense.
Thanks fellas.

Is there a name for a "redneck" programmer?

Unemployed. Wink
Offline swpalmer

JGO Coder

Exp: 12 years

Where's the Kaboom?

« Reply #4 - Posted 2004-03-11 11:04:48 »

Mechanically wrapping a variable in a getter/setter is the same as making it public.

Not exactly.  When wrapped there is  an option to override and do additional work when getting and setting the value.  (e.g. fancy caching of calculated values, marking the data as having changed or calling change Listeners.) This option is not available if you simply make the value public.
In general getters and setters are inlined at runtime so there is little or no penalty for using them, yet they provide you with hooks that might be useful in derived classes or if the implementation needs to change.

Like Herkules said, the cases for actually using a public variable exist.. e.g. when you have something that is only a data structure (has no methods at all) that you want to treat as a unit.  You may still have get/set methods in some other class that operate on this 'data' class.
Look at java.awt.Dimension for example.  It is a trivial data structure, there isn't any need to code for future extendability or anything because of the simplicity of the data you are dealing with.

Offline erikd

JGO Ninja

Medals: 16
Projects: 4
Exp: 14 years


« Reply #5 - Posted 2004-03-11 11:42:05 »

I agree with what's said here, but I think you should still be very careful not to start creating public members all the time. Especially with extending classes, you will make your code unreadable and very error prone. For example you will easily be doing 'a *= 2' instead of 'super.a *= 2' creating a bug when you have another 'a' in your sub class.
Better to use private members with getters and setters (setters of course as little as possible) by default and public members only in some circumstances where it makes sense.


Offline blahblahblahh

JGO Coder

Medals: 1

« Reply #6 - Posted 2004-03-11 12:25:09 »

In addition to the hooks argument (lets you facade classes), there's the JavaBeans argument.

If all your var's are accessed via get/set, then another app/library can use reflection to determine which vars you want people to access, and then on top of this can use the hooks to do fancy stuff - e.g. stuff which you want to do to almost ALL classes, e.g. persistence.

The examples I encounter most often are persisting data to a database and object-serialization for network transfer. In both these cases it's rather nice when you have a library which can transparently create stubs for you that e.g. read the data from the DB whenever it's needed (by overriding the methods).

However...I'm suffering a backlash against get/set's at the moment simply because of their long-windedness. It's all NIO's fault Smiley (note: NIO breaks Sun's own recommendations / coding conventions in this regard; it simply ignores the whole get/set thing). If you want to get the limit of a buffer, you use "limit()", if you want to set the position you use "position( int )", or "position()" to get it. You soon get used to reducing your typing by 2 to 4 chars for every access (normally you have to type at least "g" and sometimes the "et" as well before hitting your autocomplete button to get you to where you can start typing the variable name).

This is particularly obvious on short var names - like "a". If you have methods or vars somewhere in your environment (e.g. all public members of imported classes) called "gabby" and "gershwin", then to type "getA()" you need to type five chars minimum. If you just used "a()" then you only need type 2. That's a big difference when writing data-manipulation classes! (especially controllers and views).

malloc will be first against the wall when the revolution comes...
Offline Orangy Tang

JGO Kernel

Medals: 57
Projects: 11

Monkey for a head

« Reply #7 - Posted 2004-03-11 13:12:07 »

...and also useful for placing breakpoints in when you're thinking "which b*****d object is corrupting this variable?"

[ - Play Growth Spurt, Rescue Squad and Snowman Village ] [ Rebirth - game resource library ]
Offline bmyers

Junior Devvie

« Reply #8 - Posted 2004-03-12 16:42:39 »


The examples I encounter most often are persisting data to a database and object-serialization for network transfer. In both these cases it's rather nice when you have a library which can transparently create stubs for you that e.g. read the data from the DB whenever it's needed (by overriding the methods).

I agree.  This is exactly the case that we are using, with "heavyweight" objects that are persistent and/or serializable, and "lightweight" objects that just live for the current session.  We have had times that we made a whole bunch of heavyweight objects into lightweight ones, and vice versa.  Because we use get/set methods *everywhere* this didn't impact any of the other code because it was all an implementation detail within the objects themselves.  It saved having to edit dozens of other files to change "blah.value" to "blah.getValue()".

As far as speed of development vs. ease of maintenance and refactorability, I will always choose the latter -- probably because I expect my code to last  for several years.  As far as performance, my understanding is that the JVM will pretty much always in-line trivial get/set methods, so there's no difference in runtime performance.  Perhaps there's a small overhead in the class size.

That said, I agree with Herkules that if you want to communicate to the user of your object that there is no hidden side-effects of accessing or setting the data member, then you can make it public.  In practice, whenever I have done so, I almost always end up making it a getter/setter eventually.

Offline Jeff

JGO Coder

Got any cats?

« Reply #9 - Posted 2004-03-16 16:25:30 »

Put simply: getters and setters abstract the information from the implementation of ist storage.  This is a Good Thing for maintainability and reuse of code.

And  in any modern Java VM they cost you nothing.

The only time I *don't* use setters and getters is when the fields are on an private class that is being used strictly internally as a "struct" equivalent.

Got a question about Java and game programming?  Just new to the Java Game Development Community?  Try my FAQ.  Its likely you'll learn something!
Pages: [1]
  ignore  |  Print  

hadezbladez (1623 views)
2018-11-16 13:46:03

hadezbladez (635 views)
2018-11-16 13:41:33

hadezbladez (1613 views)
2018-11-16 13:35:35

hadezbladez (329 views)
2018-11-16 13:32:03

EgonOlsen (2672 views)
2018-06-10 19:43:48

EgonOlsen (2937 views)
2018-06-10 19:43:44

EgonOlsen (1639 views)
2018-06-10 19:43:20

DesertCoockie (2347 views)
2018-05-13 18:23:11

nelsongames (2251 views)
2018-04-24 18:15:36

nelsongames (2946 views)
2018-04-24 18:14:32
Deployment and Packaging
by philfrei
2019-02-17 20:25:53

Deployment and Packaging
by mudlee
2018-08-22 18:09:50

Java Gaming Resources
by gouessej
2018-08-22 08:19:41

Deployment and Packaging
by gouessej
2018-08-22 08:04:08

Deployment and Packaging
by gouessej
2018-08-22 08:03:45

Deployment and Packaging
by philfrei
2018-08-20 02:33:38

Deployment and Packaging
by philfrei
2018-08-20 02:29:55

Deployment and Packaging
by philfrei
2018-08-19 23:56:20 is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!