Il modo migliore per separare l'API pubblica dall'implementazione interna [chiusa]

1

Sto sviluppando un piccolo framework (in Scala) in cui voglio definire un'interfaccia pulita e semplice per gli utenti del framework. Alcune di queste interfacce devono essere implementate dal framework stesso, ma voglio nascondere queste implementazioni all'utente per mantenere la "superficie" del framework piccola e semplice.

La mia idea è di avere un pacchetto "interno" all'interno del pacchetto radice del framework in cui tutte queste cose interne entrano.

com/
  example/
    framework/
      internal/
        SomeImplementation.scala
        SomeInternalThing.scala
      SomethingPublic.scala
      SomeInterface.scala

Un'altra opzione comune è creare un pacchetto "api" per le cose pubbliche, ma ritengo che il percorso del pacchetto debba essere il più breve possibile per l'utente normale.

com/
  example/
    framework/
      api/
        SomethingPublic.scala
        SomeInterface.scala
      SomeImplementation.scala
      SomeInternalThing.scala

Un altro, più radicale, sarebbe creare due progetti separati: uno per l'API pubblica e uno per l'implementazione. Questo è essenzialmente ciò che viene fatto nel mondo Java EE. Ma questo potrebbe essere un po 'eccessivo nel possibile scenario poiché non sto creando uno standard ufficiale.

Cosa preferiresti e perché? Hai altri suggerimenti?

    
posta deamon 02.10.2015 - 21:33
fonte

1 risposta

2

Definirei sicuramente la soluzione "overkill": avere un progetto pubblico per l'API e un progetto separato per l'implementazione.

com/
  example/
    framework/
      api/
      implementation/

l'implementazione ovviamente avrà una dipendenza dall'api. Vedo 2 vantaggi:

  1. Sarà facile per te mantenere pulita la tua interfaccia API pubblica. Nessuna classe si è insinuata nell'api perché ide ha aggiunto parole chiave "pubbliche".

  2. Ho scoperto che seguire le migliori pratiche paga sempre dividendi a lungo termine. Quindi, anche se non stai creando uno standard ufficiale, seguendo questa pratica ti assicurerai di non avere problemi quando e se il tuo framework cresce nel codice e nella base di utenti.

risposta data 04.10.2015 - 09:08
fonte

Leggi altre domande sui tag