Si tratta di un buon tipo di ritorno per la progettazione delle API di Scala?

Question

vedo questo tipo di modello (found this example here) molto spesso in Scala:

class UserActor extends Actor { 
    def receive = { 
    case GetUser(id) => 
     // load the user, reply with None or Some(user) 
     val user: Option[User] = ... 
     sender ! user 
    case FindAll() => 
     // find all users 
     val users: List[User] = ... 
     sender ! users 
    case Save(user) => 
     // persist the user 
     sender ! Right(user) 
    } 
} 

Quindi, a seconda della chiamata si ottiene: Opzione [utente], Lista [utente], destro [utente]. Questo approccio va bene! Sto solo chiedendo interesse se questo è ottimale? Ad esempio (e questo potrebbe essere negativo): renderà le API migliori o peggiori per tentare di generalizzare restituendo sempre l'Elenco [Utente]? Quindi, quando un utente non viene trovato o se un salvataggio fallisce, l'elenco sarà semplicemente vuoto. Sono solo curioso .... qualche altro suggerimento su come il suddetto 'modello' può essere migliorato?

Sto solo cercando di individuare un modello perfetto per questo stile di API in cui a volte si trova una sola entità e talvolta nessuno e, talvolta, una lista di loro. Esiste un modo "migliore" per farlo, o ognuno ha il proprio ruolo?

Answer 1

I tipi restituiti dovrebbero aiutare a chiarire il comportamento previsto dell'API.

Se GetUser ha restituito un List, gli sviluppatori potrebbero confondersi e chiedersi se più utenti potrebbero essere restituiti. Quando vedono che viene restituito un Option, capiranno immediatamente il comportamento previsto.

volta ho dovuto lavorare con un API piuttosto complessa che prevedeva operazioni CRUD che erano state generalizzate in modo che si descrive. L'ho trovato difficile da capire, vagamente definito e difficile da lavorare.

Answer 2

A mio parere si tratta di un ottimo modello per la progettazione API.
Io uso molto spesso Option come tipo di ritorno delle mie funzioni, se voglio restituire un singolo elemento, ovviamente, perché non ho bisogno di trattare con null. Restituire un Seq è naturalmente per più elementi e Either è ottimale se si desidera restituire una descrizione di errore, io la uso spesso durante l'analisi di I/O. A volte combino anche lo Seq con uno degli altri. Probabilmente non conosci le preferenze e gli obiettivi di un utente della tua API, quindi è necessario fornire tutti questi tipi di reso per far sentire l'utente il più confortevole possibile.