Struttura del packaging delle raccolte Java (java.util) - perché Iterable si trova in java.lang?

Come da diagramma seguente, ad eccezione dell'interfaccia Iterable, tutti i costrutti rimanenti (interfaccia / classe / classe astratta) si trovano nello stesso pacchettojava.util

inserisci qui la descrizione dell'immagine

Perché si Iterablesiede nel java.langpacchetto?

Nota: l'intenzione è comprendere l'aspetto del packaging della programmazione Java.

— overexchange
fonte

mi chiedo perché questo sia etichettato java8 , tutte le API qui chieste sono molto più vecchie. Iterable è stato introdotto nella versione 1.5 di Java, framework delle raccolte in 1.2

— gnat

Risposte:

Come spiegato nel suo javadoc , lo scopo di Iterableè supportare una particolare sintassi del linguaggio :

L'implementazione di questa interfaccia consente a un oggetto di essere la destinazione dell'istruzione "foreach"

Come tale, appartiene al pacchetto lang , che

Fornisce classi fondamentali per la progettazione del linguaggio di programmazione Java.

Altre classi nel diagramma appartengono a JCF e quindi sono nel pacchetto util che

Contiene il framework delle raccolte ...

— moscerino
fonte

+1. Penso, tuttavia, che Iteratoridealmente dovrebbe essere presente java.lang, dal momento che lo Iterableè. Certo, deve esserlo java.utilper ragioni di retrocompatibilità (era stato introdotto nel JDK molto prima che il costrutto "foreach" gli conferisse un ruolo nel linguaggio proprio).

— Ruakh,

@ruakh Iterator è conveniente, ma probabilmente è stato considerato troppo specifico (selezione del metodo e denominazione) per passare al pacchetto "fondamentale". Pensa alla sua enumerazione precedente , che alla fine si rivelò non conveniente come si pensava inizialmente, era prudente che non andasse al pacchetto lang

— moscerino del

Il mio punto non era che fosse conveniente, ma che la lingua propria ora dipenda da questo. (Si noti che, a parte la dipendenza di Iterableon Iterator , il java.langpacchetto generalmente non dipende dalle classi in java.util.)

— ruakh

@ruakh vedo. Questo è un ottimo punto, grazie. Posso capire perché i progettisti dell'API volessero che Iterable esponesse "un oggetto che esegue l'iterazione" ma il modo in cui hanno scelto di farlo non sembra elegante

— moscerino del

Perché molte cose implementano l'interfaccia Iterable o la estendono come interfaccia secondaria.

Le classi di attuazione sono:

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

Questa è una lista enorme. E tocca tutti i tipi di pacchi là fuori.

Inoltre, si desidera ridurre al minimo le dipendenze dei pacchetti circolari . Se una classe nel pacchetto A dipende da una classe nel pacchetto B che dipende da una classe nel pacchetto A, si ha una dipendenza circolare. Non sono sempre cattivi dell'esistenza, ma portano ad altre dipendenze circolari e questa può essere una brutta cosa. Non è male da solo, ma è un odore di design che indica che l'accoppiamento tra due classi o pacchetti è troppo stretto. È l'inizio dell'accumulo del debito tecnico.

La soluzione a questo è dire "sì, l'interfaccia Iterable è qualcosa che dipende da un'ampia varietà di classi e pacchetti nell'intera struttura java e javax. Dovrebbe trovarsi nella maggior parte delle librerie di lingue - java .lang ".

Ed è qui che lo troverai.

Lettura correlata:

— Comunità
fonte