Va bene generalmente usare classi concrete da librerie OS su un'interfaccia?

I motivi per cui questa potrebbe essere una cattiva idea sono perché vuoi che il tuo programma funzioni anche quando l'interfaccia della libreria cambia, o per lo meno, devi solo cambiare poco nel tuo programma perché funzioni.

La probabilità che ti spari al piede aumenta con ogni riferimento diretto alla libreria che crei. A volte devi, ma se dovessi minimizzare le chiamate attraverso un'interfaccia di tua creazione, hai essenzialmente aggiunto un livello per ammorbidire l'accoppiamento. Fintanto che la libreria apporta modifiche ragionevoli che offrono metodi alternativi, è più probabile che non si riesca a renderli dovuti senza nemmeno alterare il programma oltre la classe di interfaccia che gestisce le classi concrete.

Allo stesso modo, gli oggetti restituiti da una libreria possono essere importanti durante il tuo programma. Dovresti incapsulare quelle istanze nelle tue classi e offrire solo metodi che usi internamente. Questo schema è talvolta chiamato Facciata . Indipendentemente dal fatto che la tua facciata agisca come una classe di biblioteche dipende interamente da te, ma sei incoraggiato a semplificare dove puoi.

Spero che ti aiuti!

Come spesso prima che la risposta sia - dipende.

Dipende interamente da quali consumatori supporti e da dove proviene questa classe concreta. Se richiedi ai consumatori di prendere una dll di cui non hanno bisogno o che vogliono solo implementare la tua interfaccia, sarebbe una pessima idea.

Diciamo che hai creato un'interfaccia ISqlSomething e hai implementazioni ISqlServiceSomething e MySqlSomething. Le implementazioni sono in diversi assembly, quindi non hanno bisogno di dipendenze su un db che non usano. In tal caso sarebbe una cosa molto brutta mettere le cose specifiche di MySql o SqlServer nell'interfaccia.

Nel tuo esempio, se non supporti casi d'uso in cui CancelationToken non è disponibile, dovresti stare bene. Un esempio potrebbe essere se si volesse supportare una vecchia versione del framework. In tal caso dovresti un'altra soluzione.

Sì, direi che CancellationToken, Exception, Task, List etc sono accettabili da esporre.

Ovviamente stai richiedendo che coloro che usano la tua libreria usino anche le librerie che contengono queste classi, e con .net Standard ora potresti voler controllare cosa è supportato da cosa! (System.Threading è in .Net Standard 2.0)

link

Ma è probabile che questo tipo di oggetti siano già in uso nella maggior parte dei progetti .net.