tl; dr: Dovrei evitare di esporre i tipi di terze parti in un'interfaccia pubblica?
Sto lavorando a un progetto basato su Kotlin basato su dati con due valori. Al momento, sto solo cercando di imparare Kotlin, ma ho pensato di pubblicarlo su un archivio pubblico come Maven Central.
In Java puro potrei memorizzare questi dati in un Map<Foo, Map<Bar, Baz>> in modo che, dato un Foo e un Bar , potrei accedervi in questo modo:
Baz someBaz = someData.get(someFoo).get(someBar)
In Kotlin, posso usare
val someBaz = someObject[someFoo][someBar]
con lo stesso effetto, che è (leggermente) più pulito. Invece, ho scelto di utilizzare la classe Table in Guava * poiché memorizza i dati esattamente in questo modo ed è notevolmente più semplice da utilizzare.
Dato che potrei pubblicare questo progetto pubblicamente, dovrei esporre (in metodi pubblici) i riferimenti alla classe guda Table , o dovrei includerli con un'API pura-Java (o Kotlin) equivalente?
Ad esempio, dovrei farlo ( Opzione 1 ):
fun doSomeProcessing(data: Table<Foo, Bar, Baz>): Table<Foo, Bar, Baz>
e semplicemente consuma e produce direttamente un Table , o dovrei farlo ( Opzione 2 ):
fun doSomeProcessing(data: Map<Foo, Map<Bar, Baz>>): Map<Foo, Map<Bar, Baz>>
e quindi avvolgere Map<Foo, Map<Bar, Baz>> in Table ?
Dovrei semplicemente operare su Map direttamente e dimenticare di usare Table * ( Opzione 3 )?
Il mio istinto dice che Opzione 1 non è una buona idea, perché sto esponendo direttamente un'API di terze parti a cui gli utenti del progetto potrebbero non piacere (probabilmente non lo faranno?) nell'uso.
D'altra parte, Opzione 2 sembra un'invisibile offuscamento; se sto davvero operando su Table , dovrei chiamarlo Table e smettere di scherzare con il wrapping in un% co_de ricorsivo.
L'opzione 3 sembra ... sbagliata. Sto già usando Guava e espone un'API molto utile che ha esattamente il tipo di struttura dati che voglio usare, e non voglio reinventare e reimplementare un po 'di codice Guava * .
* Si noti che questo non è l'unico motivo per cui sto dipendendo da Guava, e dovrei cambiare una quantità non banale di codice e reimplementare una quantità significativa di funzionalità da fare lontano con esso interamente. Quindi è un'opzione, ma non quella che sarei molto felice di prendere.