Java Help - classes question

Author

classes question

linuxnooby@yahoo.com.au

2006-04-26, 7:06 pm

Hi

I am starting my first Java program and I have a question about getting
objects to interact with each other.
In the main class I instantiate two other classes, A and B. Class A has
a public variable. But I cannot access this public variable from within
class B. If I make Class A public , the variable becomes visible from
within A, but I get a message saying that class A should be in a
separate file.

Does this mean all the classes have to be put in separate files, or is
there a way of making the variable visible to class B?

code below

cheers David

package talk;

class A {
public String hello = "Hello World";

A(){
}
}

class B {
B() {
System.out.println(a.hello);
}
}

public class test {
public test() {
}

public static void main(String[] args) {
test test = new test();
B b = new B();
A a = new A();
}
}

Mishagam

2006-04-26, 10:03 pm

Mishagam wrote:
> linuxnooby@yahoo.com.au wrote:
> problem isn't that hello is invisible. Problem is that it isn't static.
> You could use either:
> class A {
> public static String hello = "hello world";
> }
> class B {
> B() {
> System.out.println(A.hello);
> } }
>
> A instead of a as you used.
>
> Or, in you case, you could create instance of A and use form
> B() {
> System.out.println((new A()).hello);
> }
> or
> B() {
> A a = new A();
> System.out.println(a.hello);
> }
And of course a defined in main() method isn't visible anywhere but
main() method. Method variables are not visible outside methods, I think
even for anonymous classes defined inside methods.

linuxnooby@yahoo.com.au

2006-04-26, 10:03 pm

Thanks for reply
dave

Thomas Weidenfeller

2006-04-27, 4:05 am

linuxnooby@yahoo.com.au wrote:
> I am starting my first Java program and I have a question about getting
> objects to interact with each other.
> In the main class I instantiate two other classes, A and B. Class A has
> a public variable.

In your example code it doesn't. Class A doesn't have a variable at all.
So I will just guess a little bit.

> But I cannot access this public variable from within
> class B. If I make Class A public , the variable becomes visible from
> within A, but I get a message saying that class A should be in a
> separate file.

A general idea on object-oriented programming is that one does not
expose variables to the public. This is typically part of what is called
"information hiding" and is considered a good thing in OOP.

An object is supposed to have full control over the access to its
variables. An object is characterized by having state, identity, and
behavior. Object variables hold an object's state and are therefore a
crucial part of what makes up an object, and "no one" but the object
itself should mess with its state.

From the outside, users of an object should tell an object what they
expect from it, and an object should do that (the behavior part of an
object). This is typically done by using methods.

So, the typical way to change an object's state (one or more of its
variables), is to tell the object to do something via a method.
Typically, the method changes the state as a side effect of doing
something, but it has (unfortunately) also become very popular to
provide methods which just change an object's state, but doing nothing else.

In Java, methods just changing an object's internal variable/state are
called setters. Methods just reporting an object's state/variable are
called getters. By convention their names have a set/get prefix:

public class X {
private int value;
public void setValue(int value) { this.value = value; }
public int getValue() { return value; }
}

> Does this mean all the classes have to be put in separate files, or is
> there a way of making the variable visible to class B?

No, it means you have to study the Java access modifiers in more detail
and come to terms with the fact that hiding access to things is a good
thing in object-oriented programming.

/Thomas

--
The comp.lang.java.gui FAQ:
ftp://ftp.cs.uu.nl/pub/NEWS.ANSWERS...ng/java/gui/faq
http://www.uni-giessen.de/faq/archi...g.java.gui.faq/

Wojtek Bok

2006-04-27, 7:06 pm

Thomas Weidenfeller wrote:
> Typically, the method changes the state as a side effect of doing
> something, but it has (unfortunately) also become very popular to
> provide methods which just change an object's state, but doing nothing
> else.

This statement with:

> In Java, methods just changing an object's internal variable/state are
> called setters. Methods just reporting an object's state/variable are
> called getters.

confuses me.

Getters and setters are there to change the state. Sometimes they also
do some ancillary processing, but mostly they change the values of
private variables.

So in the first statement you label this as a bad thing, while in the
second statement you endorse it. So which is it?

Not trying to start a flame-war here. Just

.

I exclusively use getters/setters for all access to object variables
(state change). This has saved me where I needed a setter to also change
another state variable. A trivial example which assumes that the setting
of the name is done once, whereas retrieving the full name happens many
times:

Original:
public void setGivenName(String name)
{
ivGivenName = name;
}

Changed:
public void setGivenName(String name)
{
ivGivenName = name;
ivFullName = ivGivenName + " " + ivSurname;
}

Thomas Weidenfeller

2006-04-27, 7:06 pm

Wojtek Bok wrote:
> Thomas Weidenfeller wrote:
>
> This statement with:
>
>
> confuses me.
>
> Getters and setters are there to change the state. Sometimes they also
> do some ancillary processing, but mostly they change the values of
> private variables.
>
> So in the first statement you label this as a bad thing,

Yes, I do.

> while in the
> second statement you endorse it.

No, I don't. I just report the reality.

It is a design issue. If you just treat objects as containers for values
you end up with many setters/getters (which are still better than public
access to the internal variables). But you effectively just use them as
"link structures", the "behavior" part of objects gets largely
neglected. If you treat your objects as "things which do something", you
end up with less setters/getters and a set of methods (the "do
something" methods) which more closely resemble some real-world object.

Typically, the later results in more powerful methods, while the first
results in more, but dumber methods.

If you have the choice between public variables and setters/getters, use
setters/getters. If you have the choice between setters/getters and
methods which do more, use the later.

/Thomas
--
The comp.lang.java.gui FAQ:
ftp://ftp.cs.uu.nl/pub/NEWS.ANSWERS...ng/java/gui/faq
http://www.uni-giessen.de/faq/archi...g.java.gui.faq/

Ed Kirwan

2006-04-27, 7:06 pm

Thomas Weidenfeller wrote:
> Wojtek Bok wrote:
>
> Yes, I do.
>
>
> No, I don't. I just report the reality.
>
> It is a design issue. If you just treat objects as containers for values
> you end up with many setters/getters (which are still better than public
> access to the internal variables). But you effectively just use them as
> "link structures", the "behavior" part of objects gets largely
> neglected. If you treat your objects as "things which do something", you
> end up with less setters/getters and a set of methods (the "do
> something" methods) which more closely resemble some real-world object.
>
> Typically, the later results in more powerful methods, while the first
> results in more, but dumber methods.
>
> If you have the choice between public variables and setters/getters, use
> setters/getters. If you have the choice between setters/getters and
> methods which do more, use the later.
>
> /Thomas

I like when concepts appear on an apparently extrapolatable path like
that; makes me wonder what the, "Next," level methods would be like, if
they are to the do-more methods what the do-more methods are to the
getters/setters.

Similarly with OO itself: the power of OO stems from its separation of
interface from implementation; but what if there's more, if there's some
thing beyond-an-interface that is to interface what interface is to
implementation?

--
www.EdmundKirwan.com - Home of The Fractal Class Composition.

Download Fractality, free Java code analyzer:
www.EdmundKirwan.com/servlet/fractal/frac-page130.html

Mark Thomas

2006-04-27, 7:06 pm

.
>
> I exclusively use getters/setters for all access to object variables
> (state change). This has saved me where I needed a setter to also change
> another state variable. A trivial example which assumes that the setting
> of the name is done once, whereas retrieving the full name happens many
> times:
>
> Original:
> public void setGivenName(String name)
> {
> ivGivenName = name;
> }
>
> Changed:
> public void setGivenName(String name)
> {
> ivGivenName = name;
> ivFullName = ivGivenName + " " + ivSurname;
> }
I think the question that you should be asking yourself is why does one
object *need* access to another object's state. Ideally the object
itself should do all processing that involves its own state - that's
what Thomas was talking about in his first statement. If getters and
setters are needed, it implies that some object is performing processing
involving another object's state, and perhaps indicates that the design
needs refactoring. Getters & setters are a violation of encapsulation
and should be avoided.

Just my tuppence-worth

Mark

Wojtek Bok

2006-05-01, 7:06 pm

Mark Thomas wrote:

> I think the question that you should be asking yourself is why does one
> object *need* access to another object's state. Ideally the object
> itself should do all processing that involves its own state - that's
> what Thomas was talking about in his first statement. If getters and
> setters are needed, it implies that some object is performing processing
> involving another object's state, and perhaps indicates that the design
> needs refactoring.

public class ImageProcess
{
private float ivRotate = 0.0f;
private File ivFile = null;

public class ImageProcess(File imageFile)
{
super();
ivFile = imageFile;
}

public float getRotate()
{
return ivRotate;
}

/**
* Valid rotate value is between 0.00 and 359.99 inclusive
*/
public void setRotate( float rotate )
{
if ( rotate >= 0.0f && rotate <= 359.99f )
ivRotate = rotate;
}

public rotateImage()
{
....
}
}

Whatever calls setRotate() will certainly change the state of ImageProcess.

> Getters & setters are a violation of encapsulation
> and should be avoided.

No, the opposite is true. An object encapsulates its information and
what it is doing when it processes that information. Part of the
encapsulation is the protection of its attributes. In the above, if
ivRotate was exposed, then the value of ivRotate could be set to an
illegal value. The setter enforces proper values (and could possibly
throw an exception).

And there is no real speed penalty. The VM analyzes the getter/setter.
If all it is doing is a simple get or set (ie, no processing), then the
VM directly accesses the attribute, without going through a method call.

Sponsored Links