Структура упаковки колекцій Java (java.util) - чому Iterable сидить у java.lang?

Відповідно до нижченаведеної діаграми, крім інтерфейсу Iterable, всі інші конструкції (інтерфейс / клас / абстрактний клас) сидять в одному пакетіjava.util

введіть тут опис зображення

Чому Iterableсидить у java.langпакеті?

Примітка. Намір полягає в тому, щоб зрозуміти аспект упаковки програмування java.

— переобмін
джерело

цікаво, чому це позначено java8 , всі API, про які тут питають, набагато старші. Iterable був представлений у версії Java 1.5, фреймворк колекцій 1.2

— gnat

Відповіді:

Як пояснюється в його javadoc , мета Iterableполягає в підтримці конкретного синтаксису мови :

Реалізація цього інтерфейсу дозволяє об'єкту стати ціллю оператора "foreach"

Як такий, він належить до пакету lang , який

Надає класи, які є основоположними для дизайну мови програмування Java.

Інші класи на діаграмі належать до JCF і, отже, знаходяться в пакеті util, який

Містить рамки колекцій ...

— гнат
джерело

+1. Я думаю, що в Iteratorідеалі це також має бути java.lang, оскільки Iterableце є. Звичайно, це повинно бути з java.utilпричин сумісності з відсталою (це було запроваджено в JDK задовго до того, як конструкція "foreach" приділила йому роль належної мови).

— ruakh

@ruakh Iterator зручний, але, ймовірно, вважався занадто специфічним (вибір методу та називання), щоб перейти до "основного" пакету. Подумайте про свого попередника « Перерахунок» , який, зрештою, виявився не таким зручним, як вважалося спочатку, було доцільно, що він не пішов на поспіль пакет

— gnat

Моя думка полягала не в тому, що це зручно, а в тому, що саме від цього залежить мова. (Слід зазначити , що, крім залежності від Iterableна Iterator , то java.langпакет як правило , не залежить від класів java.util.)

— ruakh

@ruakh Я бачу. Це дуже вдалий момент, дякую. Я можу зрозуміти, чому дизайнери API хотіли, щоб Ітерабел виставив "об’єкт, який виконує ітерацію", але спосіб, який вони вирішили зробити це, не відчуває себе елегантно

— gnat

Тому що багато речей реалізують інтерфейс Iterable або розширюють його як допоміжний інтерфейс.

Реалізаційні класи:

java.util
- Анотація колекції
- AbstractList
- Анотація черги
- AbstractSequentialList
- AbstractSet
- ...
- одночасний
  - Черга ArrayBlockingQue
  - ConcurrentLinkedDeque
  - ...
java.beancontext
- BeanContextServicesSupport
- BeanContextSupport
- ...
java.sql
- BatchUpdateException
- DataTruncation
- ...
javax.management
- AttributeList
javax.print.attribute.standard
- Причини роботи
- ...
...

Це величезний список. І це стосується всіляких пакетів там.

Крім того, ви хочете мінімізувати кругові залежності пакетів . Якщо клас у пакеті A залежить від класу в пакеті B, який залежить від класу в пакеті A, у вас є кругова залежність. Вони не завжди погані в тому, що вони існують - але вони призводять до інших кругових залежностей, і це може бути погано. Це само по собі не погано, але саме дизайнерський запах вказує на те, що з'єднання між двома класами або пакетами занадто тісне. Це початок накопичення технічної заборгованості.

Рішення цього полягає в тому, щоб сказати "так, інтерфейс Iterable - це те, від чого залежить широке розмаїття класів та пакетів у всій структурі java та javax. Це повинно бути в самій базі мовних бібліотек - java .ланг. "

І саме там ви його знайдете.

Пов'язане читання:

— Громада
джерело