Question for Java devs

[Kulverstukas]

Ohai. I have a few unclear questions.
I read the Java convention book provided by Deque, which was released in 1997, assuming nothing changed in that period...

1. For setting values to variables from one class to another, my teacher always makes a separate method, like, let's say we want to set a name in a class, so my teacher would make a "setName" method to set a value to the "name" variable. Now how is this different from declaring that variable to public and setting values to it like that. I don't see much of a difference, neither I was able to find it in that conventions book.
Same this with getting a value from that variable. Instead of just grabbing the value, teacher makes a separate method.
From past coding experience in other languages, global variables are never a good idea or coding practice, even if it not said in that language's conventions.
So I assume that those are global variables in Java, therefor they need a method.

2. How would you move a mountain with a spoon?

[xzid]

2. How would you move a mountain with a spoon?

I feel the need to answer this, I used to work in a nickel mine. It's very simple, although you need a few more utensils than just a spoon.

1) Drill holes in mountain



2) Place blasting cap in booster, send down hole, fill with ANFO, wire with det cord.





3) Ka-BOOOM!!!



4) Get yourself one hell of a spoon



5) transport it



7) Use another big spoon to pile it back up

[ElectricNoodle]

Im currently doing Java and C# at college too, and I always wondered that as well, When I asked my lecturer, she said it was more to do with sticking to an Object Oriented Design, like each class should have a set of public methods/functions that are available to use, also when you access a private variable through a method it is easier to limit what can be done to it, for example: If you had an Account Class, with a private float accountBalance, you could create a method for only accessing the value, not changing it, that way it stops the front end code or other code from messing with the account balance and encapsulates it into the Account Class.

Thats why I think anyway Feel free to correct me if im wrong!

[xor]

1. Check out my response in this thread: http://evilzone.org/c-c/c-constructors-data-members-and-member-functions/msg8897/#msg8897

It's to do with Encapsulation which is part of Object Orientation. It gives you strict access to the values that a variable can be set to, it also allows you to control what access someone outside the class has to the object.

To sum up my other post. If you have a variable called speed, that you don't ever want to go over 100, then you set those parameters in your setter method. If you just made the variable public (global), then a person who instantiates that class can set the speed to what ever number they like, within the limits of the datatype.

[Deque]

The reason is that only the class should have control over its attributes. I give you an example to see the advantages:

One time you might want to know, when and how your attribute changes. If you gave public access to the variable, you need to search in every code piece of your program if it changes the variable and put a System.out.println() in this place (or some kind of logging). If you want to remove it, you have to find all those places again. In contrast a private attribute, that is only accessable via getter and setter, will need one change to show every access to it.

It is the same for similar cases like checking if the value is correct before setting it or making changes to other values everytime the variable is used or allowing only synchronized access, because you decided to use some threads. You don't want to search the whole code to do that. It spares you time (the bigger the program the more), it avoids bugs (because you forgot to change one location) and makes debugging easier.

I read the Java convention book provided by Deque, which was released in 1997, assuming nothing changed in that period...

I gave you a link to the official site. So those conventions are still relevant today, otherwise they would have changed them. Last update was 1999.