He visto una y otra vez API (especialmente en el marco de .NET) que usa Func<TObject, bool> cuando Predicate<TObject> es aparentemente una opción perfectamente responsable. ¿Qué buenas razones podría tener un diseñador de API para hacerlo?Func <TObject, bool> o Predicate <TObject>?
En LINQ, Func<T, bool> se utiliza para cosas como Where para que el otra sobrecarga que toma el índice, así como el elemento es consistente:
IEnumerable<T> Where(IEnumerable<T> source, Func<T, bool> predicate)
IEnumerable<T> Where(IEnumerable<T> source, Func<T, int, bool> predicate)
personalmente creo que el nombre Predicate es más descriptivo, por lo I lo uso en situaciones en las que no hay problema de consistencia similar a la anterior. Eso sí, hay algo que decir solo para saber sobre los tipos de delegados Action y Func ...
¿Coherencia con el resto de LINQ?
(La "anomalía" se ha señalado, pero con delegados anónimos y funciones lambda no hay diferencia, por lo que casi nunca tienen que ser conscientes de la diferencia).
Sí, pero ¿POR QUÉ LINQ lo hizo? –
Tampoco creo que la "consistencia" con el resto de LINQ sea buena razón. –
Vea la respuesta de Jon para una posibilidad. – Richard
Los Func <> delegados son la "nueva "forma de especificar lambdas/delegados a los métodos. Sin embargo, solo hay un práctico grupo de delegados, y si hay un delegado más específico que haga lo mismo, entonces vaya por eso.
En su ejemplo siempre me iría a por el predicado <> ya que es mucho más auto-documentado (suponiendo un predicado es lo que quiere)
Sí, me temo que la respuesta no va a ser mejor que esto. Es como una especie de burocracia codificada que se ganó un aspecto de pureza. (es decir, el predicado siempre debe usarse a pesar de la consistencia). –