Qual è una buona strategia per sviluppare app eseguite in console e come API?

3

Sviluppo abbastanza spesso script che sono utilizzati principalmente come un'applicazione console, ma in seguito sono utilizzati in altri script, servizi web e altre cose in cui è molto conveniente, per importare semplicemente lo script e chiamare i metodi direttamente piuttosto che utilizzare un processo e analizzando lo stdout.

La domanda è ora, qual è una buona strategia di progettazione per sviluppare tali script? Ho un esempio qui in python:

def main():
   # do stuff
   print("Found several results here:")
   for foo in bar:
       print("result: %s" % foo)


if __name__ == "__main__"():
    main()

questo potrebbe essere facilmente riscritto in qualcosa del genere:

def main():
   result = some_function()
   print("Found several results here:")
   for foo in result:
       print("result: %s" % foo)


def some_function():
   # do stuff
   return bar


if __name__ == "__main__"():
    main()

Ma nella maggior parte dei casi questo non è così facile. Ma come affrontare questo problema quando il programma fa un bel po 'di output, come diverse analisi o diversi passaggi o il valore di ritorno di una funzione API sarebbe qualcosa come una lista di dict di lista di tuple (o anche strutture più complicate) ? Sarebbe opportuno incapsulare ogni passaggio in un unico metodo e eseguirli uno dopo l'altro? Quali schemi di progettazione possono essere utilizzati per scrivere buoni programmi che possono essere facilmente riutilizzati come API?

    
posta reox 09.07.2014 - 12:14
fonte

1 risposta

5

Se stai lavorando su uno script in cui sai (o sospetti) che verrà successivamente utilizzato come una libreria in un progetto più grande, allora è più facile iniziare con la scrittura della funzionalità in una libreria e quindi taggare su un script del driver per utilizzare la libreria dalla riga di comando.

Non ci sono schemi di progettazione specifici per aiutare nella creazione di buone API. Richiede soprattutto uno spostamento nel pensare da "uno script che produce output leggibile" a "una libreria la cui uscita può essere facilmente utilizzata da altri componenti software". Il più grande cambiamento è che una libreria di solito non interagisce direttamente con l'utente.

    
risposta data 09.07.2014 - 12:41
fonte

Leggi altre domande sui tag