Devo scrivere un'API di interfaccia prima di un'implementazione?

Recentemente ho approfondito la programmazione più "organizzata" e ho imparato che avrei dovuto programmare su un'interfaccia, non su un'implementazione. Con questo in mente, sarebbe meglio "disegnare" un progetto in interfacce prima di scrivere l'implementazione per esso dove possibile?

E se questo è il caso, nel caso di utilizzo di librerie di terze parti (ad esempio Lidgren), dovrei anche avvolgere quelle nelle interfacce e risolverle attraverso i contenitori IOC, o è giusto esporle alle interfacce?

Sfortunatamente, questo spesso si riduce alle preferenze personali.

Ciò che hai descritto finora, tuttavia, sembra buono. In effetti, se volessi (e lo consiglio) potresti usare il seguente approccio:

1. Scrivi lo scheletro dell'applicazione come interfacce, classi astratte (stubbed) e classi (anche stub)
2. Scrivi i tuoi test su quelle interfacce e stub (falliranno per ora)
3. Scrivi le tue implementazioni (i test inizieranno a passare al termine dell'implementazione)

Ti stai concentrando sul tentativo di scrivere più codice "organizzato". Seguire TDD ti aiuterà in questo.

Alcuni punti extra:

• I contenitori IoC sono convenienti. Usali e DI il più possibile.
• Non avvolgere le biblioteche 3rd party. Questo allenterà l'accoppiamento tra il tuo codice (codice che controlli) e il codice di terze parti (codice che non controlli)

Sì, dovresti programmare contro interfacce piuttosto che implementazioni conosciute, e sì, dovresti prima costruire interfacce piuttosto che farle emergere dal tuo codice.

Le ragioni di entrambe le raccomandazioni sono sostanzialmente le stesse: la programmazione informatica riguarda in gran parte i fattori umani. Molti lo trovano sorprendente, ma considerano: esiste un numero pressoché infinito di modi diversi per risolvere lo stesso problema di elaborazione che funziona ugualmente bene. Quasi tutti sono completamente impossibili da dare un senso a chiunque non li abbia scritti (o in effetti all'autore poco tempo dopo).

Ne consegue che una buona ingegneria del software riguarda in gran parte il modo di ottenere l'effetto desiderato (calcolo corretto con ragionevole efficienza) in un modo che consenta di lavorare in seguito sul codice sorgente. Le interfacce e le API sono una parte cruciale di quella disciplina: ti permettono di pensare a un problema ad un livello di descrizione alla volta. Ciò è molto più semplice che pensare contemporaneamente alle regole di coerenza aziendale e alle implementazioni di elenchi collegati, pertanto è meglio imporre forzatamente una tale separazione delle preoccupazioni che consentire al programmatore del client di usare il codice nel modo che preferisce.

Questo è difficile da credere per molti programmatori di cowboy, che sono convinti di comprendere tutto ciò che scrivono, sono molto meglio dei pensatori medi e possono gestire tutta la complessità che dà problemi ai programmatori "minori". Non essere consapevoli dei propri limiti cognitivi è un fenomeno estremamente comune - ecco perché le migliori pratiche nell'organizzazione del codice sono così estremamente importanti (e così spesso ignorate).

Per ripetere, le interfacce e le barriere API sono in gran parte buone , anche quando si collabora solo con se stessi. Per quanto riguarda le librerie esterne, se portano con sé un'API ben congegnata, non vedo alcun problema nell'usarla in quanto è purché non preveda di dover sostituire quella libreria con un'altra. Altrimenti, un wrapper o un livello anticorruzione può essere un'ottima idea.

Piuttosto che programmare semplicemente per interfacce, perché non esaminare Test Driven Development / Design (TDD)?

Molte persone pensano che TDD sia una pratica di test, ma in realtà è un approccio progettuale in cui si lascia che i test espongano come il codice verrà utilizzato tramite test (inizialmente tramite test unitari, ma può anche essere tramite test di integrazione).

La programmazione alle interfacce è un'arma importante nel tuo set di strumenti, ma come la maggior parte delle cose, non è sempre la soluzione / tecnica / pratica appropriata, poiché non è sempre necessaria. È necessario programmare su interfacce dove è necessario.

L'uso di TDD ti costringerà ad esplorare dove tali interfacce sono importanti e dove, francamente, non importa. E alla fine dovresti avere un set abbastanza buono di unit test sulla tua base di codice.

Per quanto riguarda l'uso di librerie di terze parti, consiglio vivamente di includerle nelle proprie astrazioni, ove appropriato; e non lasciare che i clienti della tua API "sappiano" di loro.

In bocca al lupo!

[modifica: ho visto la risposta di megaflight - sono completamente d'accordo]

Penso che sia eccessivo. Se l'utente della tua API non ha bisogno di essere costretto a implementare / utilizzare qualcosa in un certo modo, lo lascerei fuori. Le interfacce sono contratti, se non ne ho bisogno, perché darmene uno?

Penso che le persone abusino delle interfacce. Stai aggiungendo un livello di complessità che non è necessario nella maggior parte dei casi.

Programmare contro un contratto è quasi sempre una buona idea. Quel contratto non deve necessariamente essere un'interfaccia, ma può essere adempiuto da una classe. A mio avviso, le interfacce sono state in qualche modo abusate insieme a DI a causa di problemi di test unitari e framework di simulazione.

Personalmente preferisco introdurre interfacce solo quando molto probabilmente avrei potuto o avere più di 1 implementazione di un contratto. Le interfacce sono ottime per i repository in cui desidero sottrarre l'accesso ai dati, ma probabilmente meno per la mia logica aziendale standard che è probabilmente relativamente poco flessibile.

Ora non avere un'interfaccia può causare problemi con i test unitari, specialmente per i puristi. Ma sono interessato a deridere le dipendenze esterne dei miei programmi, non le sue dipendenze interne. Voglio che i miei test eseguano la convalida del codice, non facendo eco alla struttura del codice.