Struktura pakowania kolekcji Java (java.util) - dlaczego Iterable siedzi w java.lang?

Zgodnie z poniższym diagramem, z wyjątkiem interfejsu Iterable, wszystkie pozostałe konstrukcje (interfejs / klasa / klasa abstrakcyjna) znajdują się w tym samym pakieciejava.util

wprowadź opis zdjęcia tutaj

Dlaczego Iterablesiedzi w java.langpaczce?

Uwaga: Intencją jest zrozumienie aspektu programowania Java.

— nadmierna wymiana
źródło

zastanawiam się, dlaczego jest to oznaczone java8 , wszystkie interfejsy API, o które tu pytamy , są znacznie starsze. Iterable został wprowadzony w wersji Java 1.5, framework kolekcji w wersji 1.2

— gnat

Odpowiedzi:

Jak wyjaśniono w javadoc , celem Iterablejest obsługa konkretnej składni języka :

Implementacja tego interfejsu pozwala obiektowi stać się celem instrukcji „foreach”

Jako taki należy do pakietu lang , który

Zapewnia klasy, które są fundamentalne w projektowaniu języka programowania Java.

Inne klasy na schemacie należą do JCF, a zatem znajdują się w pakiecie użytkownika, który

Zawiera strukturę kolekcji ...

— komar
źródło

+1. Myślę jednak, że tak Iteratorpowinno być java.lang, ponieważ tak Iterablejest. Oczywiście musi to wynikać java.utilz powodów kompatybilności wstecznej (zostało wprowadzone w JDK na długo zanim konstrukt „foreach” nadał mu rolę we właściwym języku).

— ruakh

@ruakh Iterator jest wygodny, ale prawdopodobnie został uznany za zbyt specyficzny (wybór metody i nazewnictwo), aby przejść do pakietu „podstawowego”. Pomyśl o jego poprzednim Wyliczeniu , które ostatecznie okazało się nie tak wygodne, jak pierwotnie sądzono, rozsądnie było, że nie poszło na pakiet

— językowy

Nie chodziło mi o to, że jest to wygodne, ale że od tego zależy właściwy język. (Należy zauważyć, że oprócz zależność Iterableod Iterator The java.langopakowanie zwykle nie zależy od klas java.util).

— ruakh

@ruakh Rozumiem. To bardzo dobra uwaga, dzięki. Rozumiem, dlaczego projektanci API chcieli, aby Iterable ujawnił „obiekt, który wykonuje iterację”, ale sposób, w jaki postanowili to zrobić, nie wydaje się elegancki

— gnat

Ponieważ wiele rzeczy implementuje interfejs Iterable lub rozszerza go jako interfejs podrzędny.

Klasy implementacyjne to:

java.util
- AbstractCollection
- AbstractList
- AbstractQueue
- AbstractSequentialList
- AbstractSet
- ...
- równoległy
  - ArrayBlockingQueue
  - ConcurrentLinkedDeque
  - ...
java.beancontext
- BeanContextServicesSupport
- BeanContextSupport
- ...
java.sql
- BatchUpdateException
- DataTruncation
- ...
javax.management
- AttributeList
javax.print.attribute.standard
- JobStateReasons
- ...
...

To ogromna lista. I dotyczy wszystkich rodzajów paczek.

Ponadto chcesz zminimalizować zależności między pakietami cyklicznymi . Jeśli klasa w pakiecie A zależy od klasy w pakiecie B, która zależy od klasy w pakiecie A, masz zależność cykliczną. Nie zawsze są złe, że istnieją - ale prowadzą do innych zależności cyklicznych, co może być złe. Sam w sobie nie jest zły, ale jest to zapach projektowy, który wskazuje, że połączenie między dwiema klasami lub pakietami jest zbyt ścisłe. To początek akumulacji długu technicznego.

Rozwiązaniem tego jest powiedzenie „tak, interfejs Iterable jest zależny od wielu różnych klas i pakietów w całej strukturze java i javax. Powinien znajdować się w najbardziej podstawowej bibliotece języków - java .lang. ”

I tam go znajdziesz.

Powiązana lektura:

— Społeczność
źródło