开发者

What is the difference in these two declarations?

开发者 https://www.devze.com 2023-04-02 10:43 出处:网络
List<String> someName = new ArrayList<String>(); ArrayList<String> someName = new ArrayList<String>();
List<String> someName = new ArrayList<String>();

ArrayList<String> someName = new ArrayList<String>();
  1. Does it impact anything on performance?
  2. The first one is a List of Objects and the latter one is ArrayList of Objects. Correct me if i am wrong. I got confused because ArrayList implements List Interface.
  3. Why do people declare like this? Does it help in any situtions.
  4. When i am receiving some email address from DB, what is the best way to collect it? List of eMail address Objects????
  5. Finally one unrelated question.... can an interface have two method names with same开发者_如何学C name and signature and same name with different signature.


The difference between the declarations is more one of style. It is preferable to declare variables using the abstract, rather than the concrete implementation, because you can change the implementation choice later without changing the variable type. For example, you might change the List to use a LinkedList instead.

If you always use the abstract type (interface or abstract class) wherever you can, especially in method signatures, the client code is free to use whatever implementation they prefer. This makes the code more flexible and easier to maintain.

This is true even of variable declarations. Consider this:

public abstract class MyListUsingClass {

    private List<String> list;

    protected MyListUsingClass(List<String> list) {
        this.list = list;
    }

    ...
}

If the variable list was declared as ArrayList, then only ArrayLists would be accepted in the constructor. This would be a poor choice: Always try to let the client code chose the implementations they want to use.

Regarding you last question: Interfaces have the same restrictions for methods as classes do, so yes you can overload methods.


  1. There is no performance impact, because in runtime you are dealing with the same class (ArrayList) in both cases.
  2. They are both lists of Strings. The difference is that the first one is declared as a List but initialized as an ArrayList, which is a more specific type of List.
  3. One instance where it helps is when you use an IDE with context-sensitive suggestions (Eclipse, NetBeans, etc). In the first case, whenever you use the suggestion feature, you will only see the members of the List interface. In the second, you will see all (public) members of ArrayList. In any given programming situation, as long as the more abstract type provides the functionality you need, you want to use that because it makes your code more robust: the more abstract a type is, the less likely it is to change in some future release of the API.
  4. The best way to represent anything always depends on what you intend to use the data for and how much of it there is. Probably a List or a Set of javax.mail.internet.InternetAddress will fit the bill.
  5. An interface can have two methods with the same name only if they have different parameter type signatures. Two methods which both take a single string cannot have the same name even if the parameters have different names, nor can you have two methods with the same name which differ only in return type.


In the first cause you're declaring a var of type list and using an ArrayList as its implementation.

In the second case you're declaring and defining an array list.

The difference is that, using the interface type (as in the first case), you will access only those methods defined in the List interface, and if ArrayList has some specific implementation methods, in order to access them you will need to cast your list to its sub-type (ArrayList).

In the second case, you're using a more specific type, so no cast is needed at all.


  1. Performance - probably not.
  2. Actually they are lists of Strings, not objects. Interfaces is not the point of what is held in Collection
  3. Defining variable of superclass type could be usefull if you would like to make your code independent of concrete list implementation. If someday you would like to change list to LinkedList implementation - this won't be so harmful to all your code
  4. Create new type EMail and store them into some kind of list (e.g. mentioned LinkedList or ArrayList) or just array (EMail[]). If you provide more information - this could be helpful.

edit 2. In both cases they are ArrayList of Strings. The difference is, that in first case you're doing casting to the superclass (losing access to some methods specific to ArrayList)


  1. Does it impact anything on performance? No measurable impact. Your code will be the source of your performance issues, not nano-optimizations like this.
  2. The first one ie s a List of Objects and the latter one is ArrayList of Objects. Correct me if i am wrong. I got confused because ArrayList implements List Interface. Exactly. You can assign a class reference to any of the types that it implements.
  3. Why do people declare like this? Does it help in any situations.The reason you might want to is in case you want to change your implementation to use another concrete class that implements List e.g. LinkedList.
  4. When i am receiving some email address from DB, what is the best way to collect it? List of eMail address Objects? Define "best". Depends on how you'll use them. Strings might be sufficient; perhaps a better abstraction would work for you.
  5. Finally one un related question.... can an interface have two method names with same name and signature and same name with different signature. Interfaces define signatures, not implementation. You can have two interfaces with methods that define the same signature, but there can only be one implementation when you execute. If you have a Cowboy and Artist interfaces, both with void draw() methods, the class that implements both will have to decide what the single implementation will be. There can't be one for Cowboy and another for Artist, because interfaces don't have any notion of implementation.
0

精彩评论

暂无评论...
验证码 换一张
取 消

关注公众号