Dove dovrei utilizzare le classi astratte e le interfacce per un client API REST?

Gli architetti over-engineering non saranno d'accordo con me, ma in un linguaggio come C #, le interfacce esistono solo per consentire l'ereditarietà multipla, e lo fanno male, senza alcuna implementazione. Cioè, se riesci a trovare un codice di implementazione comune, è meglio usare una classe base anziché un'interfaccia, tranne quando hai bisogno di qualche forma di ereditarietà multipla. Poiché C # consente solo l'ereditarietà multipla sotto forma di interfacce, sei bloccato con un'interfaccia.

Nel caso del tuo esempio specifico, non hai spiegato perché il design garantisce interfacce o classi. Quella che tu chiami "richiesta" sembra essere una combinazione di un'azione (verbi) e parametri (nomi). Questo può essere espresso in molti modi, ma il più logico per me sarebbe un oggetto composito contenente l'azione e i parametri. L'azione non deve essere specificata utilizzando una classe o un'interfaccia.

Come ha detto @Frank Hileman, le interfacce in C # non hanno implementazione e non puoi ereditare da più di una classe concreta / astratta.

Tuttavia, qui c'è più di usare le interfacce che l'ereditarietà.

Test: l'uso delle interfacce nella tua applicazione ti permetterà di "prendere in giro" un oggetto che è necessario da un altro.

Ad esempio, se si desidera testare una classe che manipola il nome di una persona in modi diversi, non si vorrebbe creare un database con tabelle e dati per memorizzare persone (con ogni variazione dei dati di test richiesti), quindi chiamare attraverso tutto il codice richiesto per recuperare quelle Persone, quindi passare quelle Persone alla classe che stai testando una per una.

Ciò non solo testerebbe la manipolazione dei dati della persona, ma tutto il codice necessario per connettersi con i dati (inclusa l'autenticazione ecc.)

Invece, vorrai che la classe che stai testando accetti un oggetto che implementa l'interfaccia per una persona. Ora puoi semplicemente creare un nuovo oggetto MyPerson: IPerson personalizzato, popolarlo con tutti i diversi valori che desideri testare, passandoli ogni volta per il test.

Garantire un oggetto implementa proprietà e / o funzionalità - indipendentemente da cosa sia effettivamente quell'oggetto:

Dove potresti voler passare un oggetto che presenta determinate funzionalità su cui potresti voler agire, non devi dover digitare type-check per ottenere i metodi o le proprietà che desideri (che potresti avere fare con classi concrete che ereditano solo da una classe astratta).

Indipendentemente dall'oggetto sottostante, le sue funzionalità esposte tramite un'interfaccia sono immediatamente ottenibili e utilizzabili.

Riutilizzo del codice:

L'uso di classi astratte per funzionalità comuni riduce il volume del codice e la possibilità di errori.

Il tuo ActionBase potrebbe avere metodi comuni come Create<T> , <T>Find(int) , List<T>Get , Update<T> e Delete<T> . Puoi implementarli in una singola classe astratta utilizzando i generici, quindi rimuovi tutto il codice dalla classe Action che normalmente manterrà tutto ( Action: ActionBase<T> ).

Riguardo alle tue entità, ancora una volta, una classe astratta terrebbe le proprietà comuni in uso. Questi possono essere l'identificatore (se il tipo di dati è comune in tutte le entità), un flag Status, DateCreated, DateModified, ecc. Se usato in tutte le entità.