Полиморфно повикване

Предимството на използването на option1, т.е. List myList = new ArrayList(); е да има полиморфно поведение по отношение на методите. Да кажем, например, че можете да имате метод, който приема аргументи от тип List,

someMethod(List lst)
{
   lst.doSomething();
   //do somethng else.....
}

В този метод lst може да бъде от тип Linked List, ArrayList или CopyOnWriteArrayList.

Вариант 1 се счита за програмиране към интерфейс, където вариант 2 е програмиране към имплементация. Последното понякога е необходимо, но първото ви предоставя възможността лесно да превключвате реализации, като гарантира, че не зависи от методите, предоставени от конкретна реализация.

Освен това, ако създавате методи, които се нуждаят само от функционалността, осигурена от интерфейс, тогава те трябва да бъдат декларирани като изискващи интерфейса, така че всеки обект, изпълняващ интерфейса, да може да им бъде предаден. Това разширява обхвата за повторна употреба на API. Например:

// This can be called passing any List
public int countItems(List lst, Filter flt) {
    // iterate list, apply filter, and count matching objects
    }

// This can called passing only an ArrayList, an unnecessary limitation in this case
public int countItems(ArrayList lst, Filter flt) {
    // iterate list, apply filter, and count matching objects
    }

Въпреки това, за някои интерфейси има скрити зависещи от изпълнението прихващания (поне в Java). Пример за това в List.get(int); ако имате ArrayList това е ефективно, но за LinkedList не е. Ако списъкът е много голям, разликата може да бъде драматична, особено за лошо замислена конструкция като този цикъл:

for(int xa=0,len=list.length; xa<len; xa++) {
    Object obj=list.get(xa);
    obj.doSomething();
    }

което има ужасна производителност за големи свързани списъци, тъй като списъкът трябва да бъде обхождан от самото начало за всеки get(xa).