API interna dell'applicazione

Question

API interna dell'applicazione

#1 da (9 voti)

5

Attualmente sto costruendo una piccola applicazione python CLI (Command Line Interface) con ambizione. Nella prima fase di sviluppo mi concentrerei sul fatto di farlo funzionare solo attraverso l'interfaccia CLI , ma nella seconda fase lo farò funzionare attraverso un GUI .

Per evitare un sacco di refactoring delle funzionalità e mantenere entrambe le versioni in esecuzione su un codice simile, stavo pensando di sviluppare la mia API interna per gestire l'elaborazione.

IE:

Caricamento del file di configurazione
Salvataggio del file di configurazione
Informazioni sulla registrazione (tramite CLI o file di registro)
E il processo generale dell'applicazione

Mi stavo chiedendo da dove iniziare e cosa tenere a mente durante la creazione di un'API interna?

Ho già guardato la seguente presentazione: Come progettare una buona API e perché è importante o leggere il versione testuale

** Quello che intendo per API è: Se voglio caricare le configurazioni devo solo fare qualcosa come config = api.load.config(path/to/config/file) e otterrei un dictionnary (o object , ancora da determinare ) senza dover rilevare il tipo di file e se il file esiste, quella parte sarebbe gestita dal framework API interno

api-design api

posta JF Dion 21.03.2011 - 20:33

fonte

1 risposta

Leggi altre domande sui tag api-design api

Mercato Android aziendale interno Esiste una simbologia matematica comune per le raccolte?

score 9 · Accepted Answer

Poiché la lettura e la scrittura di file di configurazione sono già parte di Python, così come i file di registro, non è necessario eseguire alcuna progettazione API.

Basta leggere e usare. È già stato fatto per te.

link

Per il resto della tua applicazione, non pensarci troppo. Anzi, meno pensi e meglio è.

La tua applicazione (o CLI o GUI) consente a un attore di interagire con oggetti di determinate classi. Queste classi principali definiscono il tuo modello. È lo stesso in tutte le presentazioni (CLI, GUI, WEB).

In primo luogo, progetta le classi modello. Queste classi dovrebbero essere in un pacchetto ordinato (o meglio, un singolo modulo) e dovrebbero funzionare da script e test unitari.

In secondo luogo, progettare la CLI che utilizza quelle classi sottostanti.

Le classi sottostanti sono - essenzialmente - un'API. Ma non leggere un sacco di cose sulla progettazione dell'API. Disegna bene le classi sottostanti.

In terzo luogo, progettare la GUI che utilizza le classi sottostanti. Durante questa operazione, avrai l'urgenza di ridefinire la tua CLI e la progettazione del tuo modello per rendere tutto più semplice e più pratico. Questo è buono.

Ma non leggere un sacco di cose sulla progettazione dell'API. Basta rifattorizzare bene le classi.

Il segreto è questo.

Test unità

Una volta che hai un buon test unitario per il tuo modello, puoi rifattorizzare la CLI e la GUI ed essere sicuro che tutto funzioni. Non aver paura di refactoring. È più facile costruire qualcosa che funzioni e refactoring piuttosto che leggere un libro sulla progettazione dell'API, progettare l'API e quindi imparare un sacco di lezioni difficili sul fatto che la tua applicazione del mondo reale sia leggermente diversa dalle applicazioni ideali del libro di testo .