Są to decyzje projektowe, a jeden rozmiar zwykle nie pasuje do wszystkich. Również wybór tego, co jest używane wewnętrznie dla zmiennej członka, może (i zwykle powinno być) różnić się od tego, co jest wystawione na świat zewnętrzny.
W swojej strukturze środowisko kolekcjonowania Java nie zapewnia kompletnego zestawu interfejsów, które opisują właściwości bez ujawniania szczegółów implementacji. Jedyny interfejs opisujący wydajność, RandomAccess
jest interfejsem znacznika i nawet nie rozszerza zakresu Collection
lub nie wyświetla ponownie interfejsu API get(index)
. Więc nie sądzę, że jest dobra odpowiedź.
Zgodnie z ogólną zasadą, utrzymuję typ tak niespecyficzny, jak to możliwe, dopóki nie rozpoznaję (i nie udokumentuję) jakiejś cechy, która jest ważna. Na przykład, gdy tylko będę chciał wiedzieć, że zachowane zostało zamówienie reklamowe, zmieniłabym z Collection
na List
i udokumentuję, dlaczego to ograniczenie jest ważne. Podobnie, przejdź od List
do LinkedList
, jeśli powiemy, skuteczne usuwanie z przodu staje się ważne.
Jeśli chodzi o udostępnianie kolekcji w publicznych interfejsach API, zawsze staram się ujawniać tylko te kilka interfejsów API, które powinny zostać użyte; na przykład add(...)
i iterator()
.
Kolekcja to interfejs implementowany przez LinkedList. Zawsze powinieneś wskazywać interfejs przy wdrażaniu. – emd