Come fa il progettista dell'API pubblica a giungere alla conclusione cosa deve essere fornito per il futuro e cosa no?

0

Spesso lavorando con vari vasi ed esplorando le funzionalità specialmente nei casi angolari, spesso mi rendo conto e penso che in questo modo hanno pensato che potrebbe essere uno scenario utile da qualche parte in futuro che potrebbe essere utilizzato e un'API resa utile. Quindi, come arrivano alla conclusione cosa deve essere fornito e cosa no?

Altro problema che ho dovuto affrontare una volta era che avevo bisogno di una determinata funzionalità e mancava dalla lista che mi colpiva con l'immenso inconveniente di usare le API.

Non dovrebbe essere che se manca qualche funzionalità allora il programmatore dovrebbe essere in grado di programmarlo da solo piuttosto che dipendere interamente dalle API in ogni momento?

    
posta Rorschach 21.03.2013 - 07:10
fonte

1 risposta

2

La scrittura dell'API è davvero uno dei compiti più difficili dell'informatica. Ovviamente è possibile esporre semplicemente tutto ciò che si ha e lasciare che le persone usino ciò che vogliono. Ciò impedisce il tuo secondo problema: un'attività che il codice chiaramente potrebbe fare, ma che non puoi fare tramite l'API.

Purtroppo, questo è l'unico vantaggio di esporre tutto. Lo svantaggio è che l'API diventa più difficile da capire, più è grande, e meno chiaramente è organizzata. Un'API che è fonte di confusione da utilizzare non viene utilizzata da molte persone (a meno che non abbia un "punto di vendita unico"), quindi gli autori di codice cercano di rendere le proprie librerie facili da capire. Ma la piccolezza e la chiarezza sono quasi impossibili da ottenere con un approccio "tutto è pubblico", quindi devi scegliere cosa esporre, se consentire a Un modo giusto di fare qualsiasi cosa o blocchi ortogonali facili da usare ma che possono essere combinati senza restrizione.

Questa è una chiamata molto difficile da fare. Gli interi linguaggi di programmazione seguono diversi principi su questo punto (Perl afferma ufficialmente che c'è più di un modo per farlo, mentre Python preferisce che ci sia un modo ovvio per farlo), quindi non sorprende che anche i singoli programmatori siano in disaccordo.

Per quanto riguarda cosa permettere in primo luogo ... può dei progetti di programmazione di maggior successo iniziare come qualcosa che l'autore fa per i propri bisogni immediati. Quando qualcosa funziona bene, sembra coerente e sembra qualcosa che gli altri potrebbero volere, allora la gente inizia a chiedersi se potrebbe aver senso pubblicarla come una biblioteca. A questo punto possono accadere cose molto diverse. Alcuni programmatori prendono solo il set di cose per cui usano il codice e lo pubblicano. Potrebbero rispondere al feedback della community aggiungendo altre chiamate API, oppure potrebbero ignorarle completamente. Altri intervistano i possibili utenti in anticipo e cercano di trovare una serie di metodi che consentano loro di fare quello che vogliono, ed è ancora ragionevolmente ben progettato. (Altri ancora intervistano possibili utenti e includono assolutamente tutto suggeriscono ...)

(Va anche notato che il design API non viene quasi mai insegnato ai programmatori di inizio nel modo in cui la programmazione strutturata, i principi OO, o anche la gestione dei progetti e il controllo di revisione vengono ora insegnati di routine. troppo raro per essere insegnato ai programmatori in generale.)

    
risposta data 21.03.2013 - 08:36
fonte

Leggi altre domande sui tag