Ho visto più volte API (in particolare nel framework .NET) che utilizza Func<TObject, bool> quando Predicate<TObject> è un'opzione apparentemente perfettamente responsabile. Quali motivi validi per potrebbero avere un progettista API per farlo?Func <TObject, bool> o Predicate <TObject>?
In LINQ, Func<T, bool> è usato per cose come Where in modo che il altro sovraccarico che prende l'indice così come l'elemento è coerente:
IEnumerable<T> Where(IEnumerable<T> source, Func<T, bool> predicate)
IEnumerable<T> Where(IEnumerable<T> source, Func<T, int, bool> predicate)
personalmente credo che il nome Predicate è più descrittivo, in modo da mi lo uso in situazioni in cui non c'è nessun problema di consistenza come quella qui sopra. Intendiamoci, c'è qualcosa da dire solo per conoscere i tipi di delegati Action e Func ...
Coerenza con il resto di LINQ?
(L ' "anomalia" è stato notato, ma con i delegati anonimi e funzioni lambda non fa alcuna differenza, in modo quasi mai bisogno di essere a conoscenza della differenza.)
Sì, ma PERCHE 'LINQ lo ha fatto? –
Inoltre, non penso che la "coerenza" con il resto di LINQ sia una ragione valida per . –
Vedi la risposta di Jon per una possibilità. – Richard
Le Funz <> delegati sono il "nuovo "modo di specificare lambda/delegati ai metodi. Tuttavia, c'è solo un pratico insieme di delegati, e se c'è un delegato più specifico che fa la stessa cosa, allora faccia quello.
Nel tuo esempio ho sempre andare per il predicato <> in quanto è molto più auto-documentazione (assumendo un predicato è quello che volete)
Sì, temo che la risposta non migliorerà. È come se una sorta di codice burocratico conquistasse un aspetto di purezza. (Ad esempio, il predicato dovrebbe sempre essere usato nonostante la coerenza). –