Qual è il modo più elegante per scrivere un metodo "Try" in C # 7?

Sto scrivendo un tipo di implementazione della coda che ha un TryDequeuemetodo che utilizza un modello simile a vari TryParsemetodi .NET , in cui restituisco un valore booleano se l'azione ha outesito positivo e utilizzo un parametro per restituire il valore effettivo dequeued.

public bool TryDequeue(out Message message) => _innerQueue.TryDequeue(out message);

Ora, mi piace evitare i outparametri ogni volta che posso. C # 7 ci fornisce delcarazioni variabili per facilitare il lavoro con loro, ma continuo a considerare i params più un male necessario che uno strumento utile.

Il comportamento che desidero da questo metodo è il seguente:

• Se c'è un oggetto da dequeue, restituiscilo.
• Se non ci sono elementi da accodare (la coda è vuota), fornire al chiamante informazioni sufficienti per agire in modo appropriato.
• Non restituire un articolo null solo se non ci sono articoli.
• Non generare un'eccezione se si tenta di accodare da una coda vuota.

In questo momento, un chiamante di questo metodo userebbe quasi sempre un modello come il seguente (usando la sintassi della variabile out C # 7):

if (myMessageQueue.TryDequeue(out Message dequeued))
    MyMessagingClass.SendMessage(dequeued)
else
    Console.WriteLine("No messages!"); // do other stuff

Non è il peggiore, tutto sommato. Ma non posso fare a meno di pensare che potrebbero esserci modi migliori per farlo (sono totalmente disposto a ammettere che potrebbe non esserci). Odio come il chiamante deve interrompere il suo flusso con un condizionale quando tutto ciò che vuole è ottenere un valore se ne esiste uno.

Quali sono alcuni altri schemi esistenti per realizzare questo stesso comportamento "provare"?

Per il contesto, questo metodo può potenzialmente essere chiamato nei progetti VB, quindi punti bonus per qualcosa che funzioni bene in entrambi. Tuttavia, questo fatto dovrebbe avere un peso molto ridotto.

Utilizzare un tipo di opzione, vale a dire un oggetto di un tipo con due versioni, in genere chiamato "Some" (quando è presente un valore) o "None" (quando non è presente un valore) ... O occasionalmente si chiamano Just and Nothing. Esistono quindi funzioni di questi tipi che ti consentono di accedere al valore se è presente, verificare la presenza e, soprattutto, un metodo che ti consente di applicare una funzione che restituisce un'ulteriore Opzione al valore se è presente (in genere in C # questo dovrebbe si chiama FlatMap anche se in altre lingue viene spesso chiamato Bind invece ... Il nome è fondamentale in C # perché avendo il metodo s di questo nome e tipo si usano gli oggetti Option nelle istruzioni LINQ).

Funzionalità aggiuntive possono includere metodi come IfPresent e IfNotPresent per invocare azioni nelle condizioni pertinenti e OrElse (che sostituisce un valore predefinito quando non è presente alcun valore ma non è altrimenti operativo) e così via.

Il tuo esempio potrebbe quindi assomigliare a:

myMessageQueue.TryDeque()
    .IfPresent( dequeued => MyMessagingClass.SendMessage(dequeued))
    .IfNotPresent (() =>  Console.WriteLine("No messages!")

Questo è il modello monade Opzione (o Forse) ed è estremamente utile. Esistono implementazioni esistenti (ad es. Https://github.com/nlkl/Optional/blob/master/README.md ) ma non è difficile neanche per te.

(Potresti voler estendere questo modello in modo da restituire una descrizione della causa dell'errore invece di nulla quando il metodo fallisce ... Questo è interamente realizzabile e spesso viene chiamato Ouna monade; come suggerisce il nome puoi usare la stessa FlatMap modello per rendere facile lavorare anche in quel caso)

Le risposte fornite sono buone e vorrei andare con una di esse. Considera questa risposta semplicemente riempiendo alcuni angoli con alcune idee alternative:

• Crea sottoclassi di Messagechiamato SomeMessagee NoMessage. Dequeueora può tornare NoMessagese non è presente alcun messaggio e SomeMessagese è presente un messaggio. Se la persona interessata si preoccupa di rilevare il caso in cui si trova, può farlo facilmente mediante l'ispezione del tipo. Se non lo fanno, beh, semplicemente NoMessagenon fanno nulla ogni volta che viene chiamato uno dei suoi metodi e, ehi, ottengono ciò che hanno chiesto.

• Come sopra, ma rendi Messageimplicitamente convertibile in bool(o implementa operator true / operator false). Ora puoi dire if (message)e far sì che sia vero se il messaggio è buono e falso se è cattivo. (Questa è quasi certamente una cattiva idea, ma la includo per completezza!)

• C # 7 ha tuple. Restituisce una (bool, Message)tupla.

• Crea Messageun tipo di struttura e ritorna Message?.

In C # 7 è possibile utilizzare la corrispondenza dei motivi per ottenere lo stesso in modo più elegante:

if (myMessageQueue.TryDequeue() is Message dequeued) 
{
     MyMessagingClass.SendMessage(dequeued)
} 
else 
{
    Console.WriteLine("No messages!"); // do other stuff
}

In questo caso particolare, probabilmente userò gli eventi piuttosto che eseguire il polling ripetutamente della coda.

Non c'è niente di sbagliato in un metodo Try ... (con un parametro out) per uno scenario in cui il fallimento (nessun valore) è altrettanto comune del successo.

Ma, se insisti a fare le cose in modo diverso, potresti voler restituire un messaggio vuoto e inviarlo (non più il tuo problema) o rimandare l'istruzione if fino a quando non devi davvero sapere se hai un messaggio con contenuto o meno.

Si noti che qualcuno deve comunque eseguire il test qualche volta. Direi che il test dovrebbe essere fatto quando e dove la domanda è attuale. Questo è al momento del dequeing.