I'm trying to store variables generated in one class to an array in another class.
i.e (pseudo code):
Class example
{
x = 2+2;
}
Class stuff
{
array[0] = example.x;
}
why doesn't this work.
Name:
Anonymous2013-07-26 9:20
Make 'em public static.
Name:
Anonymous2013-07-26 9:21
Or make 'em public and NOT static, then make some variables of class example and store their x's.
Name:
Anonymous2013-07-26 9:25
Make 'em not Java.
Name:
Anonymous2013-07-26 9:25
Or just fucking inherit stuff from example.
Name:
Anonymous2013-07-26 9:49
could you explain why public static worked?
Name:
Anonymous2013-07-26 9:54
I recommend reading a fucking book on programming.
Name:
Anonymous2013-07-26 9:57
>>6
public => accessible from everywhere, even from outside the class
static => there is only one x per class, instead of every class variable having its own x.
Name:
Anonymous2013-07-26 9:57
public and private is just conceptual crap. It just does not make sense, not is useful in any way.
>>9
I almost never use private and I have never use protected
Name:
Anonymous2013-07-26 10:12
It's typical to make variables private to their class and then use getter and setter methods.
So, like this:
Class example {
private int x;
public void setX(int val) {
x = val;
}
public int getX() {
return x;
}
}
Then, in other places in code you would do
example exampleObj = new example();
exampleObj.setX(10);
System.out.println( exampleObj.getX() );
Hope this helps!
Name:
Anonymous2013-07-26 10:16
>>12
Wow! Useless crap! Thank you so much! Also, please learn to use code tags!
Name:
Anonymous2013-07-26 10:17
/prog/, I never really got why you would want to use get and set methods. Is there any purpose in creating tons of cookie cutter methods?
Name:
Anonymous2013-07-26 10:23
>>13
Yes, encapsulation is useless. Learn to derive classes, jackass.
>>14
Encapsulation allows you to add error checking around your setting methods, meaning you won't be fucking up any data by rounding down when you should be rounding up, because you check and make sure in your set method. Additionally, you cut down on code copying.
I could go on and on. People who don't encapsulate data act like hard-asses, but as an employed software engineer I can tell you that it is useful, and you need to know how and why to do it to gain employment.
Name:
Anonymous2013-07-26 10:27
>>15
Employment AND knowledge of OO programming? That's pretty impressive! Not many people can claim that! You have impressed me! Impressive!
Name:
Anonymous2013-07-26 10:36
>>16
It's funny because you even know it's an OO language, but you refuse to use it like one. Kill yourself.
Name:
Anonymous2013-07-26 10:41
>>17
I don't use it at all. What kind of schmuck connard would use an ``abstract, high-level'' language with a syntax derived from another language engineered specifically to implement video drivers and filesystems?
>>15
Exposing your fields like a cheap whore isn't ``encapsulation'', you enterprise dipshit. It doesn't matter dick that you are mutating your objects's fields with getters and setters, and that you can keep calling the same methods if the semantics changed, because you can't know how it affects the rest of the code. You already made your code tightly coupled by exposing those fields as an interface in themselves, that it was through getters and setters is a meaningless detail.
You know, Java doesn't actually have encapsulation. Using reflection makes public, private, final, etc. no more binding than //PLS don't set this to 0!!! thx <3