Posted by mrnorman [send private reply] at July 22, 2002, 10:48:50 PM

Also, there's the JavaBeans architecture to consider. If you're writing code that is to be used by others who follow, you need to code according to a standard so it's all compatible. A common standard is JavaBeans (there are books on it and stuff). According to JavaBeans, you shouldn't use fields, but rather 'setter' and 'getter' methods. If this is just random code though, it doesn't matter, lol.

Posted by taubz [send private reply] at July 21, 2002, 08:24:43 PM

Using fields versus methods doesn't really make your program any less object oriented. The only reason you'd want a method is if you can forsee needing to take some action when X is changed. If you don't care when X is changed, and you're sure no one will want to make a subclass of myObject's class that will want to take an action when X is changed, there's no reason why not to use a field.

My two cents.

- taubz

Posted by infryq [send private reply] at July 21, 2002, 10:54:46 AM

Okay, so I'm helping Zandalf do this, and am running into some repeating issues, one of which is OO in general. My question is:

What's the general consensus on how OO to make something? Is it considered Bad to write

 myObject.x=5; 

over

 myObject.changeX(5); 

and if so, what degree of issue is this? The code we're working with is in http://www.rivard.org/lobster/java/ . pointdemo.java is his original code, kpointdemo.java is my edit, for OO principles and so it compiles(had some issues figuring out how constructors were supposed to be used).

Anyhow, beginners take a look at the two files, figure out what got changed, and why. More experienced people, thoughts on the questions above? To what degree of OO-ness is generally acceptable?