What would be the best way to call a static method named eatApples from a method called main within a class called Apples
Is there any difference between Apples.eatApples(); and eatApples();, regarding efficiency or any other thing in general?
There won't be any difference between the bytecode generated for Apples.eatApples(); and eatApples();. Performance wise both would be same.
There are actually 3 ways to write it:
Apples.eatApples();
eatApples();
this.eatApples(); // Don't do this!
They all mean exactly the same thing and have identical performance. The only difference is readability.
The first one makes it clear to the reader that a static method is being called (assuming that you follow standard Java naming convention!)
The second one is less clear, but you can easily look for the declaration to check if the method is static or not.
The third one is misleading. Using this is "flagging" to the reader that the method is an instance method. But it isn't.
This question already has answers here:
class or method alias in java
(8 answers)
Closed 3 years ago.
I have a class with a probably unnecessarily cumbersome name, that contains a lot of static methods I use elsewhere.
Rather than fill my code with a lot of
VeryUnnecessarilyLongCumbersomeName.doThingFoo();
VeryUnnecessarilyLongCumbersomeName.doThingBar();
VeryUnnecessarilyLongCumbersomeName.doThingEgg();
VeryUnnecessarilyLongCumbersomeName.doThingSpam();
I would rather have
VeryUnnecessarilyLongCumbersomeName thing = new VeryUnnecessarilyLongCumbersomeName();
thing.doThingFoo();
thing.doThingBar();
thing.doThingEgg();
thing.doThingSpam();
However, this gets the warning
"the static method doThingFoo() should be accessed in a static way."
I know there are multiple solutions here. Use better class names. Make it not static. Ignore it because it's just a warning.
But I don't actually think it should be a warning. What harm does doing it this way cause? Is there a more elegant/correct way to make my code less clunky that isn't one of the above solutions?
NOTE: I suspect this might warrant the coding-style tag and therefore be considered off-topic and get rejected. I was thinking there's room here for a question like this, however, so I leave it up to y'all.
Although it is not technically harmful because it technically works, the problem with this is it is misleading, and any values that the instance thing contains, do not actually matter at all for the results of the methods.
Typical Java Convention:
When accessing a method through an instance, one would expect the result to be dependent on the values of the instance.
When accessing a method through a Class name, one would expect the result to be independent of the values of any instance.
Your way:
You are accessing a method through an instance and expecting it to be independent of any instance.
So why use an instance for an instance independent method? That is why it is misleading. I would suggest attempting to shorten the class name rather than accessing static methods through an instance.
How about changing the VeryUnnecessarilyLongCumbersomeName class?
Static methods are there to be used without instances. They are meant to be used if you want to invoke the method without first initializing a class. The downside of using static methods is that you lose all kinds of OOP benefits; You lose virtual dispatch and subsequently polymorphism. You can never override that method in a derived class. Of course you can declare a new (static) method in a derived class, but any code that accesses it has to be aware of the entire class hierarchy and do explicit checking and casting, which is precisely what OO is supposed to avoid.
Also, it is confusing. When another programmer sees your code, he/she will think upon seeing a static he/she will assume that it will not require a valid instance to invoke the method.
TLDR; don't do it and stick with the best practices =)
When calling a method, I get that you have to use instanceName.method() or className.method(). However, in some cases the instanceName or className is omitted in the code and just method() is written.
Programming language is Java. Just covering this for the AP Computer Science test and I have relatively limited knowledge of coding outside of the parameters of the course so a easy to understand explanation would be greatly appreciated.
My book says something about client programs but I'm not exactly sure what it means (both in general and about client programs specifically).
I'll put my explanation as simply as possible - Usually you would use instanceName.method() when trying to effect the variables within a class. For example a "Cat" object, you could make a cat - Cat catOne = new Cat() and then use its methods catOne.setName("Kitty");. This will set this objects name to "Kitty", leaving all other cat objects with the ability to have their own unique name.
Using className.method() is done when using a static method within a class, eg public static int method(), and then using it in another class. This does not require you to instantiate an object for that class, and can use them willingly. For example, having a class called MathConstants and using something like MathConstants.getPi() ( Sorry for the crude example ).
When methods are called like methodName() , this means that the method is located within the class itself. Usually we use this , as in this.methodName(), but just using methodName() is okay.
Hope that is easy to understand
So I'm learning Java (gasp bet you could've never guessed that), and today I'm focused heavily on making sure that I'm using static methods properly.
My big practice program right now is an account manager program, that I tweak and add to as I learn more and more concepts. One component of it is printing out a list of all the accounts added to the system. Because this list gets summoned more than once, I created a static method that can be invoked to generate it, and placed it above my main method in the code.
My question is: should I do this? Is it a good idea/good programming etiquette to create methods like this for repetitive sections of code? And if the answer to both of those is yes, should I make it a static method?
Here's the code for the static method I'm talking about:
/**
* accountList() method displays a list of all accounts currently loaded into the program
*/
public static void accountList(){
System.out.println(" ACCOUNT LIST");
System.out.println("NUMBER INFORMATION");
for(int num = 0; num < accountArray.size(); num++){
System.out.println(" " + (num + 1) + " " + accountArray.get(num).getAccountName()
+ " : " + moneyFormat.format(accountArray.get(num).getValue()) + " "
+ accountArray.get(num).getCurrencyType());
}
listMax = accountArray.size();
}
Then below this would be my main() method, and periodically within my main would be the invocation of this method to generate an account list:
public static void main(String[] args){
accountList(); //example of how I would invoke this method
}
So, do I have this figured out properly? Am I using this correctly? Thanks.
PS. My accountList() method is in the same class as my main() method, which is why there's no class name before it. That's also why I'm asking, because I know one of the main purposes of the term "static" is that it would be easily accessible from another class, so I'm not sure if it needs to be static if it's in this same class.
Is it a good idea/good programming etiquette to create methods like this for repetitive sections of code?
Having many small methods in stead of fewer large methods is a good practice in terms of maintainability and re-usability.
should I make it a static method?
Static methods are used when they do not depend on state of some particular instance of the class. It is in general avoided since subtype polymorphism is not available for static methods (they can't be overridden). Small utility methods are made static (like Math.sqrt or System.currentTimeMillis()).
Note: (Optional)
When you define methods to re-use the code, the most important aspect is the contract that the method is supposed to fulfill. So the methods should communicate with each other using arguments and return values for predictable behavior. Mutating state of class fields (or even worse static fields) is generally considered a bad idea (you have to do it though sometimes).
You could improve your method to something like following.
public static void printAllAccounts(List<Account> accountList) {
// Your code ...
}
This method specifies which accounts to print, and does not depend on state.
It would be even better if you can delegate it to another class and make it a non static behavior. That way if you come up with better way of printing all accounts, you can replace the behavior without touching this method.
Hope this helps.
Good luck.
Don't repeat yourself (DRY) is a widely accepted principle and good practice, and creating methods for code that would otherwise be duplicated is the simplest and most obvious form for this.
(In some languages/contexts people hint at the potential overhead of a method invocation and its impact on performance. In fact, inlining methods is a common optimization that compilers do. But modern compilers (and particularly, the Just-In-Time-Compiler of the Java Virtual Machine) do this automatically when it is appropriate)
Whether helper methods should be static has already been discussed elsewhere.
My rule of thumb here is: Whenever a method can be static, then it should be static.
A more differentiated view: When a method does not modify instance fields (that is, when it does does not operate on a mutable state), but instead only operates on its arguments and returns a result (and is a "function", in that sense), and when it should not be involved in any form of polymorphism (meaning that it should not be overloaded), then it should usually be made static. (One might have to take aspects of unit testing into account here, but that might lead too far now)
Concerning your specific example:
You have a different problem here: The accountArray obviously is a static field, as well as the listMax variable. And static (non-final, mutable) fields are usually a horrible idea. You should definitely review this, and try to make sure that you do not have static fields that describe a state.
If you did this, your method could still be static, and receive the accountArray as a parameter:
public static void accountList(List<Account> accountArray){
System.out.println(" ACCOUNT LIST");
...
}
However, in this form, it would violate another best practice, namely the Separation of Concerns. The method does two things:
it creates a string representation of the accounts
it prints this string to the console
You could then split this into two or three other methods. Depending on the indented usage, these could, for example, be
public static String createAccountInfoString(List<Account> accounts) {...}
public static void printAccountInfo(List<Account> accounts, PrintStream ps) {
ps.println(createAccountInfoString(accounts));
}
public static void printAccountInfo(List<Account> accounts) {
printAccountInfo(accounts, System.out);
}
(note that the method names indicate what the methods do. A method name like accountList doesn't tell you anything!).
However, as others have pointed out: Overusing static methods and passing around the information may be a sign of not properly using object-oriented concepts. You did not precisely describe what you are going to model there. But based on the keywords, you might want to consider encapsulating the account list in a class, like a class AccountList, that, among others, offers a method to print an account list to a PrintStream like System.out.
Here's what a static method is. A static method from the same class, you can just call without the class name, but a static method from another class, you would have to call with the class name. For example, if you have a static method called method1 in a class called Class1, and you're trying to call the method in a different class called Class2, you would have to call the method like this:
Class1.method1();
If you just use method1(), it would show up as an error, and it'll tell you that it can't find the method, because it only searches the class you're in for the method, and it doesn't find it. You would have to put the class name, Class1, so it knows to go search for the method in Class1, and not the class you're in.
As for whether you should use a static method or not, that depends, really, on your preference. Do you know the different between a static method, and a non-static one? I'll just gives you the basics for now. If you have more questions, you can ask.
Okay. A non-static method can only be called when you make an object out of the class the method is in. This is how you make an object:
(CLASS NAME)(OBJECT NAME) = new (CONSTRUCTOR NAME)();
The constructor's name is the same as the class name. And when you call the method, you would put (OBJECT NAME).METHOD NAME(); to call it. As for a static method, I already told you how you can call it. So. Anymore questions?
The use of static methods is something that could remember procedural programming. In fact, if you use static methods you cannot use OOP principles, like polymorphism.
First of all, it is not good that a method, which aims is to print a list, could change program state. Then, in the future, you may want to change the way the list is printed. Let say, you want to print it in file. How would you change your program to satisfy this new requirement if your ar using a static method?
Try to think more OO, and in the beginning, try to put your code inside a dedicated class (i.e. Printer). Then, you can extract an interface from that class, and finally try to apply some design patterns, like Strategy Pattern or Template Method Pattern.
static members of a class (that is variables, method) are not related/associated to the instance/object of the class. They can be accessed without creating object of the class.
General rule of using static method is - "Ask yourself is the property or method of a class should applicable for all of the instance of the class". If the answer is yes then you may use static member.
Consider the following example -
public class Student{
private int noOfStudent;
.......
}
Now you have a Student type. In this case you may consider to make the noOfStudent property static. Since this is not the property of a Student itself. Because all students of a class should share the same property of noOfStudent.
You can find more explanation here
Hope it will Help.
Thanks a lot.
Assuming all method calls here are static, like this:
public class Util {
public static void method1() {
}
}
Accessing in a static way:
Util.method1();
Util.method2();
Util.method3();
accessing in a non static way
Util util = new Util();
util.method1();
util.method2();
util.method3();
Is there any performance difference for either way? I know the first way of doing it here is accessing it properly. But the second way only instantiates the util object once as opposed to three times. I can't find anything pointing to anything other than to be accessing these methods properly. From what I can tell there is no functional difference, but a logical difference. Looking for sort of a cost vs. benefit of either way if anyone knows.
Is there any performance difference for either way?
Yes - the second is marginally slower, due to a pointless instance being constructed.
I know the first way of doing it here is accessing it properly. But the second way only instantiates the util object once as opposed to three times.
No, the second way creates one instance of Util whereas the first way doesn't create any instances.
The first way is significantly better, because it makes it clear that it is a static method. Consider this code:
Thread t = new Thread(someRunnable);
t.start();
t.sleep(1000);
What does it look like that last call does? Surely it makes the new thread sleep, right? No... it just calls Thread.sleep(), which only ever makes the current thread sleep.
When you mangle a static method call to act "through" a reference, the value of the reference is completely ignored - it can even be null:
Util util = null;
util.method1(); // This will still work...
There's no difference for the code you show, since all those methods are static. (The compiler will issue a warning for the second group, however.) I think there's a small performance benefit to static methods. The underlying byte code for static access, invokeSpecial I think, should be faster than invokeVirtual, which has to do some type decoding.
But it's not enough to worry about. Use whichever type of method (static vs. instance) is right for your design. Don't try to optimize the method calls like that.