I don't really understand what the point is of giving Methods variable arguments. i.e
void showVars(int one, int two) {
//etc.
}
Whats the point in declaring one and two in the method and not just in the body of the code? Sorry, I realise this is probably a stupid question...
consider this...
public int addNumbers( int num1, num2){
return num1+num2
}
by doing this, i can add up any two int's and get a result...
int a = 5;
int b = 10;
int c = 15;
int d = 25;
// some more code...
int sum1 = addNumbers( a,b);
int sum2 = addNumbers ( a,c );
int sum3 = addNumbers( b,d);
// so on....
hope that helps you understand...
- MaxxDmg...
- ' He who never sleeps... '
The variables "in the class' body" are known as member variables. They are class variables (static) or instance variables (non-static). The idea is that they represent state. Class variables represent state for the class, and instance variables represent state for the object (the instance of the class).
Method arguments represent input to the method. Sometimes the method may use or manipulate the state of the object. But sometimes the method may need data that's not properly part of the state of the object, so we pass it as a parameter.
For instance, a String object has an array of characters as an instance variables that represents that String's state.
It has a method length() that doesn't take any parameters. It simply returns information about the string's state--the number of characters in that string.
It also has a method charAt(int index) that takes an int as a parameter and retrieves the character at that position. It wouldn't make sense to simply have an instance variable called index. That's not part of the string's state. You're asking for some information about the state, but not the whole state, just a piece, so you use the parameter to specify which piece of the state.
For private methods, where an object is just calling it's own methods as decomposition of a problem into smaller pieces, you have more latitude. Often times you could either pass data from method to method to method, or you could just make an instance variable that holds the data from one call to the next. I tend to go with the former, unless it really makes sense that that data exists as part of the object's state independent of any method calls in progress.
> Well, how would two different objects pass
> information to one another if constructors and
> methods didn't take arguments?
Public member variables.
(Note to barkera0: DON'T do this. It's bad idea and leads to brittle, hard-to-understand, hard-to-maintain code.)
> > Well, how would two different objects pass
> > information to one another if constructors and
> > methods didn't take arguments?
>
> Public member variables.
>
>
> (Note to barkera0: DON'T do this. It's bad idea and
> leads to brittle, hard-to-understand,
> hard-to-maintain code.)
I knew this but I just assumed the OP knew that this would be a bad way of sharing information among objects.
