Nella mia API, come posso rendere superflui conoscere i dettagli di implementazione?

Pensaci in questo modo: quando uno sviluppatore nuovo di zecca si unisce al team, lo assegnerai a una determinata area del progetto. Non vorresti che fosse in grado di aggiornarsi su quella sezione del progetto in modo da poter completare il suo incarico, o vuoi che trascorra tre mesi ad apprendere l'intero massiccio edificio?

O da parte tua - supponi di spendere un sacco di tempo in un altro progetto e devi correggere un bug, non ti piacerebbe essere in grado di limitare l'ambito delle tue attività di debug?

(C'è un metodo qui, aspetta.)

API sta per Application Programming Interface. Nulla in questo nome definisce a quale scopo è definito. A mio parere, ogni classe ha un'API. Pensando sempre a come la classe verrebbe utilizzata altrove, puoi rendere ogni classe, pacchetto, servizio web e così via facile da usare e mantenere.

Mentre elabori il tuo progetto in un primo momento, vedrai diverse sezioni di grandi dimensioni. Ad esempio, in un'applicazione per lo shopping, puoi scomporlo in Scorte, Fatturazione e Spedizione. Ognuno di questi avrà cose specifiche di cui hanno bisogno per comunicare tra loro. Ognuno di quelli a sua volta può essere ulteriormente suddiviso. Finisci con un albero. Le applicazioni più facili da mantenere non comunicano tra i rami di questo albero in modi non definiti, come l'utilizzo di campi pubblici, statica pubblica e singleton. Devono solo preoccuparsi dei campi e degli oggetti che possiedono, attraverso l'interfaccia pubblica di quell'oggetto: la sua API .

Tutto ha un'API. Quello di cui dovresti preoccuparti è se l'API sia o meno facile da usare, manutenibile e testabile, e non se ne hai bisogno. Un'interfaccia ben definita ti aiuta a limitare l'ambito delle aggiunte di funzionalità, del bug-squashing e della curva di apprendimento di tutti.

Penso che dovresti sempre cercare di definire un'API il prima possibile. Per questi motivi:

1. Aiuta davvero a definire i requisiti.
2. Aiuta a definire in termini concreti ciò che ogni membro del team dovrebbe fare.
3. Aiuta a gestire l'ambito: quando tutti i requisiti sono soddisfatti, le tue API sono completate.
4. Puoi più facilmente scambiare implementazioni diverse. Questo aiuta se stai provando o semplicemente provando nuovi modi di fare le cose. Devi ancora soddisfare gli stessi requisiti, ma puoi farlo in modi diversi e poi decidere cosa è meglio - tempo permettendo.

Ci sono probabilmente altri buoni motivi, ma questi sono i motivi principali per cui lo faccio in questo modo.

Penso che sovraccaricherebbe "API" per dire che è necessario farlo qui, ma sicuramente concentrarsi sulle interfacce pubbliche che integreranno e co-mantengono i casi di test sono cose molto utili da fare in anticipo. In questo modo abbiamo letteralmente una conversazione che va così "questi sono i metodi che mi aspetto che le tue classi forniscano, e qui ci sono alcune specifiche che dovrebbero passare per fornire la funzionalità che mi aspetto".

È solo una "API" se la chiami così. Non sono sicuro che tu abbia qualche connotazione negativa con questo, ma i contratti tra i moduli di codice logico sono una buona cosa, anche se sei l'unico sviluppatore. E i contratti sono rigidi o flessibili come te e il tuo team hanno bisogno che siano.

Buona architettura generale mantenuta da qualche parte in un wiki / Moduli di proprietà di singoli o due (team virtuali) / interfacce / test di integrazione ben definiti attorno a questi moduli e al controllo del codice sorgente.