4

Possible Duplicate:
Why should the interface for a Java class be prefered?
What is the benefit of polymorphism using Collection interface to create ArrayList object?

I see in many examples that when one creates an instance of some collection like TreMap, he uses it's base as type:

Map<String,String> theMap = new TreeMap<String,String>();

Why not to use 

TreeMap<String,String> theMap = new TreeMap<String,String>();
Community
  • 1
  • 1
kenny
  • 2,000
  • 6
  • 28
  • 38
  • 4
    possible duplicate of [Why should the interface for a Java class be prefered?](http://stackoverflow.com/questions/147468/why-should-the-interface-for-a-java-class-be-prefered), [What is the benefit of polymorphism using Collection interface to create ArrayList object?](http://stackoverflow.com/questions/3356113/what-is-the-benefit-of-polymorphism-using-collection-interface-to-create-arrayli), [List versus ArrayList](http://stackoverflow.com/questions/4062982/list-versus-arraylist) and possibly more. – BalusC Nov 01 '11 at 15:12
  • It is very good that you are asking. Some people do not understand this and do not ask and write concrete classes in the left part of assignment. Doing this is a crime. – AlexR Nov 01 '11 at 15:15

5 Answers5

5

Because it's considered a better practice to code to the interface (Map) instead of the implementation (TreeMap). This way you are free to switch to a different implementation (e.g. HashMap, if you later decide it is a better solution) with minimal code touch-points.

maerics
  • 151,642
  • 46
  • 269
  • 291
3

It's generally better to code to an interface, not an implementation, which allows an implementation change without having to change code that refers to it.

The only time it's reasonable to not do this is when code relies on characteristics of a specific implementation. For example, if the code requires the fast indexed list item access ArrayList provides, it might make sense to force a specific implementation.

Dave Newton
  • 158,873
  • 26
  • 254
  • 302
1

In general it is better to program against Interfaces because it is easier, e. g., to switch from TreeMap (ordered) to HashMap (maybe faster).

If you use interfaces when possible, you only have to change one sourcecode part.

H-Man2
  • 3,169
  • 20
  • 19
1

The reason is Liskov substitution principle. Directly quoted what was said.

Let q(x) be a property provable about objects x of type T. Then q(y) should be provable for objects y of type S where S is a subtype of T.

Simple explanation

  • Map is an interface
  • And an interface is a contract

While using a Map we confirms that, we are using the contract of what a Map is supposed to do.

For example

  1. doSomething(Map<String, String> map)
  2. doSomething(TreeMap<String, String> map)

doSomething(Map<String, String> map) gives option to use any implementation which confirm the contract of Map allowing any of its subtype to work.

Whether doSomething(TreeMap<String, String> map) accepts any subtype of TreeMap. But TreeMap is not a contract so any subtype of TreeMap can violates its signature/behavior(methods actually). Thus making TreeMap less preferable compare to Map. Composition over inheritance can give u more idea about this.

Kowser
  • 8,123
  • 7
  • 40
  • 63
0

This is one of java best pratices: program using interfaces if you can.

This helps to make you application more flexible because the method that receives this Map can also work on the other implementations of Map, but the method that received TreeMap can only use TreeMap and it's childrens.

So you get freedom to modify your method workings if you latter find that a HashMap would improve your application speed.

Cristiano Fontes
  • 4,920
  • 6
  • 43
  • 76