IEnumeruojamas <T> nulinis susiejimas

Dažnai IEnumerable<T> su problema, kad patikrintumėte, ar IEnumerable<T> nulinis prieš rūšiavimą per foreach ar LINQ užklausas, ir tada aš dažnai įvedu tokius kodus:

 var myProjection = (myList ?? Enumerable.Empty<T>()).Select(x => x.Foo)... 

Todėl maniau, kad šį išplėtimo būdą pridėti prie plėtinių klasės:

 public static class MyExtensions { public static IEnumerable<T> AsEmptyIfNull<T>(this IEnumerable<T> source) { return source ?? Enumerable.Empty<T>(); } } 

Mano nuomone, svarstant šį kodą kyla nedidelė problema, t. Y. atsižvelgiant į išplėtimo metodų „pavyzdžių metodų metodą“, jis turi būti įgyvendinamas kaip paprastas statinis metodas, kitaip kažkas panašaus būtų visiškai teisėtas:

 IEnumerable<int> list = null; list.AsEmptyIfNull(); 

Ar matote bet kokį kitą jo naudojimo trūkumą?
Ar toks išplėtimas gali sukelti tam tikrą blogą tendenciją kūrėjo (-ų) atveju, jei jis yra masyviai naudojamas?


Premijos klausimas:

Ar galite jam suteikti geresnį vardą? :)
(Anglų kalba nėra mano pirmoji kalba, tada aš ne taip gerai pavadinu ...)

Ačiū iš anksto.

5
12 апр. nustatyti digEmAll 12 bal 2011-04-12 22:15 '11, 10:15 PM 2011-04-12 22:15
@ 2 atsakymai

Metodai, kuriais grąžinamas „ IEnumerable<T> turėtų grįžti į tuščią, o ne nulinę. Taigi jums to nereikia.

Žr. Šį klausimą: Ar geriau grąžinti tuščią arba tuščią kolekciją?

Priešingu atveju jūsų kodas atrodo gerai.

7
12 апр. atsakymas mathieu 12 balandis. 2011-04-12 22:18 '11 10:18 val. 2011-04-12 22:18

Paprastai yra bloga idėja grąžinti null o ne tuščią seką, jei galite ją valdyti. Tai savaime suprantama, jei manote, kad kai kas yra paprašyta sukurti kolekciją, grįžimas į null toks, kaip „kolekcija yra tuščia“, bet „visai nėra tokios kolekcijos“.

Jei turite metodų, kuriais grąžinami skaičiuojami objektai, tada grąžinkite tuščią IEnumerable (kuris netgi gali tapti statiniu tik skaitytu objektu, jei jis gali būti grąžintas daug) - kelias, laikotarpis.

Jei esate priverstas naudoti blogą stilių turinčią biblioteką, kuri tokiais atvejais turi įprotį grįžti į null , šis sprendimas gali būti sprendimas, bet aš to nenoriu. Tikriausiai geriau uždaryti nesąžiningus metodus savo versijose, kurios derinamos, kai žmonės jų nemato. Tokiu būdu jūs gaunate būtinybę būti visuomet suskaičiuotam, o ne null ir „nepagrįsto“ paradigmos nepalaikymo teisingumui.

3
12 апр. Atsakymą pateikė Jonas balandžio 12 d 2011-04-12 22:27 '11 prie 22:27 pm 2011-04-12 22:27