Accessing Outside Class Methods
Hey, just got a quick question for you guys...
I was wondering what is the better way to do the following or what determines how you should do the following:
Say I'm in a GUI class and I want to access a method ( printINFO() )from a different class outside of the GUI class (lets call this class Bob), now from what I have learned so far I know I can't directly access the class via "Bob.printINFO();" without getting an error message saying that it can not access non-static message from a static context. So what I want to know is that when I declare a Bob variable in the field how should I declare it...
Should I just:
"public Bob myBob;"
Or should I make a new object out of it:
"public Bob myBob = new Bob();"
Both will allow me to access methods from the class (myBob.printINFO();), but how do I determine what one is best to use?
Thanks
[901 byte] By [
sharokua] at [2007-11-27 5:30:31]
Use the one that actually works
To invoke an instance (non-static) method, you absolutely must have an instance to invoke it on, so you need to actually call new Bob(). The first one cannot possibly work, because you haven't created an object. What you've got there is your basic recipe for a NullPointerException
First note that this has nothing to do with the fact that one class "is a GUI".
So we could rephrase the problem as follows: Suppose we have the following:
class A {
public void printInfo() {}
}
class B {
void f() {
*I want to invoke printInfo from here!*
}
}
What are your options?
1. Pass an instance of A to f:
void f(A a) {
a.printInfo();
}
2. Create an instance of A as a local variable in f:
void f() {
A a = new A();
a.printInfo();
}
3. Create an instance of A as a field in B:
class B {
private A a = new A();
void f() {
a.printInfo();
}
}
4. Create an A property in B and assume another object sets the property:
class B {
private A a;
public void setA(A a ) {
this.a = a;
}
public A getA() {
return a;
}
void f() {
getA().printInfo();
}
}
Other options include adding another layer of indirection on each of the
above. For example assume the following exists, or can be designed.
class C {
public A getA() {...}
}
Then the above 4 options become the following.
1'. Pass an instance of C to f:
void f(C c) {
c.getA().printInfo();
}
2'. Create an instance of C as a local variable in f:
void f() {
C c = new C();
c.getA().printInfo();
}
3'. Create an instance of C as a field in B:
class B {
private C c = new C();
void f() {
c.getA().printInfo();
}
}
4'. Create an C property in B and assume another object sets the property:
class B {
private C c;
public void setC(C c) {
this.c = c;
}
public C getC() {
return c;
}
void f() {
getC().getA().printInfo();
}
}
HTH
> HTH
Wow, first I would just like to say that your post is probably the most helpful post I have ever received in response to a question in well, quite frankly, my entire life. In fact, I copied your posted and saved it in a text file for future reference. =)
Anyways, the only thing that really gets me from your post is, in what kind of case would I want to add another layer of misdirection? I mean wouldn't that just make things overly complicated? Besides that, your post was very helpful and I thank you much.
> misdirection
Surely some mistake.
Anyway, it's hard to motivate some things in the abstract. You have to really start with a specific example.
But here's another example of indirection that's actually got
a name: The Mediator Pattern:
http://www.javacamp.org/designPattern/mediator.html
The idea here is suppose you have several objects, say eight,
and each one sends the others (or most of the others)
messages. What a knot! The mediator steps in: it knows
all eight objects, but they only know it. They send messages
to only it, and it does the rest.
They say every problem can be solved by adding one more
level of indirection, especially if you're allowed to apply
this rule recursively ;-)
