Le mie classi API interne dovrebbero essere tutte in un unico pacchetto?

Question

Sono al lavoro per impacchettare un'API per il consumo pubblico. Come tale sto cercando di limitare i metodi che sono esposti solo a quelli che desidero essere pubblici e sostenibili. Sotto questo, naturalmente, ci sono una moltitudine di metodi ad accesso limitato.

Il problema è che ho un sacco di codice interno che deve accedere a questi metodi ristretti senza rendere pubblici quei metodi. Questo crea due problemi:

• Non riesco a creare interfacce per comunicare tra le classi in quanto questo renderebbe questi miei metodi interni pubblici.
• Non riesco ad accedere ai metodi protetti o predefiniti a meno che non inserisca la maggior parte delle classi interne nello stesso pacchetto .

Quindi, ho circa 70 o 80 classi interne in pacchetti separati ma MA con modificatori di accesso eccessivamente permissivi. Diresti che un singolo pacchetto è il minore di due mali o esiste un modo migliore per essere in grado di mascherare i miei metodi interni mantenendo pacchetti più granulari?

Sarei interessato a scoprire le migliori pratiche qui.

Sono già a conoscenza di This

Answer 1

Ci sono due soluzioni alla tua domanda che non implicano il mantenimento di tutte le classi nello stesso pacchetto.

Il primo è utilizzare il modello Friend Accessor/Friend Package descritto in (Practical API Design, Tulach 2008).

Il secondo è utilizzare OSGi. C'è un articolo here che spiega come OSGi realizza questo.

Domande correlate: 1, 2, 3 e 4.

Answer 2

Un esempio potrebbe essere la Servlet API come si vede sono separati comuni API servlet e http in due pacchetti.

Se si separa il codice in un api.jar e implementation.jar, è possibile utilizzare le interfacce per l'implementazione che non sono visibili agli utenti di api.jar. Se oggetti di classi indipendentemente dal loro pacchetto, devono collaborare in alcun modo, i metodi ovviamente devono essere visibili (almeno nell'implementazione).

Answer 3

sì, non è possibile proteggere l'implementazione interna dall'accesso. Ci sono alcune tecnologie (come OSGi), che offrono una soluzione a questo durante l'avvio di applicazioni/runtime. Questo è un difetto di modularizzazione del linguaggio java (ma anche molto difficile da aggiungere in seguito a causa di problemi di compatibilità).

mi piace la convenzione di aggiungere artefatti visibili pubblicamente a /api pacchetto e interni a /interno. Alla fine finisci con.

 

# this package is allowed to be accessed by api-users 
com.foo.users.api 
# this is completely internal logic (api implementation) 
# should only be touched by the api-module itself. 
com.foo.users.internal 
 

In questo modo si ha una separazione netta e si possono anche eseguire regole del codice di analisi del codice statico.

Come con la servlet-api menzionata sopra, è possibile dividere ulteriormente api vs impl in diversi vasi. Ma questo comporta un maggiore sforzo per costruire-il ciclo di vita e mantenere i moduli, quindi lo farei solo laddove una suddivisione di artefatto di runtime completa abbia senso (come in jsr-spec vs. impl).