This question already has answers here:
What is the exact meaning of static fields in Java?
(4 answers)
Closed 7 years ago.
I am reading a code one of my friends wrote to store the account of users using arraylist. So he declared private static ArrayList = new ArrayList<>(); I understood this part, but I am not sure why he has declared it as static. That brought me up to this question : When is it a good idea to declare a data structure static?
That's a question that calls for a very delicate answer, but:
When is it a good idea to declare a data structure static?
NEVER
Static members are the root of many evils. They make the class less reusable. They make the class harder/impossible to test. They make the class non thread safe by default, which can be remedied but it's difficult to get right and can cause performance issues. They put the responsibility of managing the resource in the wrong place.
This is a very big OOD topic that's been discussed to great extents, so I'll just point out a commonly used acronym that is worth looking up: SOLID principles.
Related
This question already has answers here:
What does it mean to "program to an interface"?
(33 answers)
Closed 5 years ago.
I was a bit confused, when we use
List<String> lst = new LinkedList<>();
when we use
LinkedList<String> lklst = new LinkedList<>();
At the beginning, I thought they are the same, but today, I realized they are not the same. For example, if I call lst.getFirst() It will tell me there is a error. However, if i do lklst.getFirst(), it works fine. My question is when do we use lklst then? why they are different? Also, does it apply same rule for Map. THanks!
On the left hand side you're declaring the type of the variable, lst. Since lst's type is List you can only access methods of a List, even if the object lst points to is really a LinkedList. There's an inherent tradeoff between declaring a variable of a concrete type like LinkedList (access to more methods / behavior) vs. a more abstract interface (safer, better compartmentalized code).
This is a big topic, and there isn't one simple answer for when to do one vs. the other (though there's lots of advice out there about it!) - you'll need to figure out which is appropriate for your use case.
Effective Java - Item 52: Refer to objects by their interfaces is a pretty canonical citation for this issue, and as the title implies suggest preferring List rather than LinkedList.
This question already has answers here:
What is the difference between an Instance and an Object?
(25 answers)
Closed 5 years ago.
I think I have read some about this topic but just let me put it clear:
I ask this to differentiate a little more "object" and "instance", although in Oracle Java tutorial I haven't seen the word "instance". I think the tutorial author avoided this expression intendedly.
https://docs.oracle.com/javase/tutorial/java/concepts/
But, inspired by some other questions here, I think there are two questions which will end this dispute:
Is every instance considered an object?
(I guess is)
and,
Is every object in Java, or in OOP, considered an instance?
(I guess no, because I think "instance" are "concrete object instantiated from a class". If an object is not constructed from instantiation, it's not an instance. However correct me if I am wrong).
In my understanding, "object" come from OOP where we see each and every concrete thing as an abstract concept, named "object". And, "instance" come from "instantiation", means "the result of a process of concretion from some class, which is a prototype.", which I have mentioned above. They are concepts with different origins but at last, in practical situations, often refer to the same thing.
If the answer to these two questions are undoubtful "YES", then they are the same. Again, correct me if I have a logical error here.
PS:
When adding tags, I see that definitions in tags of "instance" and "object" are similar.
To make it simple, an instance is a representation (unique) of an Object.
This question already has answers here:
Best Practice: Java static non final variables
(7 answers)
Closed 9 years ago.
After a couple of years using Java i've just realized that i don't understand what it the use case for non-final static variables. Can someone give me some hints or any example?
Maybe they are needed to be used in static methods? ... or useful to be shared between all instances?
What concerns me is they can be accessed and modified asynchronously by any subclass, or through any instance.
Thanks.
** note **
Sorry about duplication. I did my search before posting and i didn't find it.
As constants they have no use, which I believe is your main trails of thoughts are concentrated around.
But how do you think a static class is going to perform it's operations if there is any need for class scope variables that need to be shared across the method calls?
Or there are instances where data need to be stored in a static class etc.
There are a lot of use cases if you just stop to think about it.
This question already has answers here:
What is a good use case for static import of methods?
(16 answers)
Closed 2 years ago.
I declare some constant variables in my SQLiteOpenHelper class:
public static final String USERNAME = "user_name";
public static final String PASSWORD = "password";
In an Activity where I create SQL queries, I import these fields:
import com.mygame.ui.login.LoginInfoSQLiteOpenHelper.*;
Is this a good practice?
Or the traditional way of referring to constants better?
LoginInfoSQLiteOpen.USERNAME
If you look at someone's code and see a field like
foo.do(baz, USERNAME);
wut(!), where did that var come from ?
search, grep, where is it declared ?
Using it as ClassName.FIELD makes things much clearer and cleaner.
You avoid confusion, and sometimes it makes more sense to have a proper classname that denotes the field, than a field that came out of nowhere.
well, not everyone uses an IDE, and not everyone reads code through an IDE(maybe through a repository on the web), and even some consider VIM an IDE, and I do use vim a lot(although I don't think of it as an IDE).
So, it's not about what an IDE can or can't do, but more of what code reading is about. Code reading, code quality, expressing ideas in your programming language of choice, in a way through abstractions that make sense and tie well together.
A few years late to the party... but I feel it is worth providing the opposite point of view. There is a reason why Java was designed to have static field imports, and the reason is to hide how the class is implemented to users of the class. This is an important design principle for outwardly facing code. I would agree with c00kiemon5ter take on it, however, there might be situations in which it is worthwhile.
More info on static field importing can be found here: https://docs.oracle.com/javase/1.5.0/docs/guide/language/static-import.html
I recommend the second method, only importing classes not fields. So prefixing your constants with the owning class, like LoginInfoSQLiteOpen.USERNAME. It can become highly redundant, but it is much more readable and maintainable in the long run.
This question already has answers here:
Closed 12 years ago.
Possible Duplicate:
Why is String final in Java?
I'm just wondering why java.lang.String is made final? Is it to prevent from being inherited? Why?
Yes indeed. This allows code in security managers and classloaders to work with the String type without having to worry that it's actually dealing with a malicious subclass that's specifically designed to trick it into allowing evil code through.
You should not be extending the string class. Just write your own methods in some other class that manipulate strings.
The reason is that the string class is a stable one which should not be tampered with as you may re-define some methods which would have unknown side effects on some other transactions.
Aside from security aspects that were already mentioned, I suspect performance was another important reason. For older JVMs especially final classes (where all methods are final by definition) made it much easier to inline code on-the-fly. And since String is one of most heavily used objects, which affects overall performance of many applications, this was seen as an area where improvements would have big overall effect.