Przekazywanie pojedynczego elementu jako IEnumerable <T>

Czy istnieje wspólny sposób przekazywania pojedynczego elementu typu Tdo metody, która oczekuje IEnumerable<T>parametru? Językiem jest C #, wersja ramowa 2.0.

Obecnie używam metody pomocniczej (to .Net 2.0, więc mam całą masę rzutowych / rzutujących metod pomocniczych podobnych do LINQ), ale to po prostu wydaje się głupie:

public static class IEnumerableExt
{
    // usage: IEnumerableExt.FromSingleItem(someObject);
    public static IEnumerable<T> FromSingleItem<T>(T item)
    {
        yield return item; 
    }
}

Innym sposobem byłoby oczywiście utworzenie i wypełnienie pola a List<T>lub an Arrayi podanie go zamiast IEnumerable<T>.

[Edytuj] Jako metodę rozszerzenia może mieć nazwę:

public static class IEnumerableExt
{
    // usage: someObject.SingleItemAsEnumerable();
    public static IEnumerable<T> SingleItemAsEnumerable<T>(this T item)
    {
        yield return item; 
    }
}

Czy coś mi umyka?

[Edytuj2] Odkryliśmy someObject.Yield()(jak sugeruje @Peter w komentarzach poniżej), że jest to najlepsza nazwa dla tej metody rozszerzenia, głównie ze względu na zwięzłość, więc tutaj jest wraz z komentarzem XML, jeśli ktoś chce go złapać:

public static class IEnumerableExt
{
    /// <summary>
    /// Wraps this object instance into an IEnumerable&lt;T&gt;
    /// consisting of a single item.
    /// </summary>
    /// <typeparam name="T"> Type of the object. </typeparam>
    /// <param name="item"> The instance that will be wrapped. </param>
    /// <returns> An IEnumerable&lt;T&gt; consisting of a single item. </returns>
    public static IEnumerable<T> Yield<T>(this T item)
    {
        yield return item;
    }
}

Twoja metoda pomocnicza to najczystszy sposób, aby to zrobić, IMO. Jeśli przekażesz listę lub tablicę, nieuczciwy fragment kodu może rzucić go i zmienić zawartość, co w niektórych sytuacjach może prowadzić do dziwnego zachowania. Możesz użyć kolekcji tylko do odczytu, ale może to wymagać jeszcze większego zawijania. Myślę, że twoje rozwiązanie jest tak schludne, jak to tylko możliwe.

Cóż, jeśli metoda oczekuje IEnumerable, że musisz przekazać coś, co jest listą, nawet jeśli zawiera tylko jeden element.

przechodzący

new[] { item }

jak sądzę, argument powinien wystarczyć

W C # 3.0 możesz użyć klasy System.Linq.Enumerable:

// using System.Linq

Enumerable.Repeat(item, 1);

Spowoduje to utworzenie nowego IEnumerable, który zawiera tylko twój element.

W C # 3 (wiem, że powiedziałeś 2) możesz napisać ogólną metodę rozszerzenia, która może sprawić, że składnia będzie nieco bardziej akceptowalna:

static class IEnumerableExtensions
{
    public static IEnumerable<T> ToEnumerable<T>(this T item)
    {
        yield return item;
    }
}

kod klienta jest wtedy item.ToEnumerable().

Ta metoda pomocnicza działa dla przedmiotu lub wielu.

public static IEnumerable<T> ToEnumerable<T>(params T[] items)
{
    return items;
}    

Jestem trochę zaskoczony, że nikt nie zasugerował nowego przeciążenia metody argumentem typu T, aby uprościć interfejs API klienta.

public void DoSomething<T>(IEnumerable<T> list)
{
    // Do Something
}

public void DoSomething<T>(T item)
{
    DoSomething(new T[] { item });
}

Teraz twój kod klienta może po prostu to zrobić:

MyItem item = new MyItem();
Obj.DoSomething(item);

lub z listą:

List<MyItem> itemList = new List<MyItem>();
Obj.DoSomething(itemList);

Albo (jak już powiedziano)

MyMethodThatExpectsAnIEnumerable(new[] { myObject });

lub

MyMethodThatExpectsAnIEnumerable(Enumerable.Repeat(myObject, 1));

Na marginesie, ostatnia wersja może być również przyjemna, jeśli chcesz mieć pustą listę anonimowych obiektów, np

var x = MyMethodThatExpectsAnIEnumerable(Enumerable.Repeat(new { a = 0, b = "x" }, 0));

Jak właśnie znalazłem i zobaczyłem, że użytkownik LukeH również sugerował, ładny prosty sposób na zrobienie tego jest następujący:

public static void PerformAction(params YourType[] items)
{
    // Forward call to IEnumerable overload
    PerformAction(items.AsEnumerable());
}

public static void PerformAction(IEnumerable<YourType> items)
{
    foreach (YourType item in items)
    {
        // Do stuff
    }
}

Ten wzór pozwoli ci wywołać tę samą funkcjonalność na wiele sposobów: pojedynczy element; wiele elementów (oddzielonych przecinkami); tablica; lista; wyliczenie itp.

Nie jestem jednak w 100% pewien skuteczności użycia metody AsEnumerable, ale to działa.

Aktualizacja: funkcja AsEnumerable wygląda całkiem wydajnie! ( odniesienie )

Chociaż jest to przesada w przypadku jednej metody, uważam, że niektórzy ludzie mogą uznać Interaktywne rozszerzenia za przydatne.

Interaktywne rozszerzenia (Ix) firmy Microsoft obejmują następującą metodę.

public static IEnumerable<TResult> Return<TResult>(TResult value)
{
    yield return value;
}

Które można wykorzystać w następujący sposób:

var result = EnumerableEx.Return(0);

Ix dodaje nową funkcjonalność, której nie znaleziono w oryginalnych metodach rozszerzenia Linq, i jest bezpośrednim wynikiem utworzenia Reactive Extensions (Rx).

Pomyśl, Linq Extension Methods+ Ix= Rxdla IEnumerable.

Możesz znaleźć zarówno Rx, jak i Ix na CodePlex .

Jest to 30% szybsze niż yieldlub w Enumerable.Repeatprzypadku użycia z foreachpowodu optymalizacji kompilatora C # i tej samej wydajności w innych przypadkach.

public struct SingleSequence<T> : IEnumerable<T> {
    public struct SingleEnumerator : IEnumerator<T> {
        private readonly SingleSequence<T> _parent;
        private bool _couldMove;
        public SingleEnumerator(ref SingleSequence<T> parent) {
            _parent = parent;
            _couldMove = true;
        }
        public T Current => _parent._value;
        object IEnumerator.Current => Current;
        public void Dispose() { }

        public bool MoveNext() {
            if (!_couldMove) return false;
            _couldMove = false;
            return true;
        }
        public void Reset() {
            _couldMove = true;
        }
    }
    private readonly T _value;
    public SingleSequence(T value) {
        _value = value;
    }
    public IEnumerator<T> GetEnumerator() {
        return new SingleEnumerator(ref this);
    }
    IEnumerator IEnumerable.GetEnumerator() {
        return new SingleEnumerator(ref this);
    }
}

w tym teście:

    // Fastest among seqs, but still 30x times slower than direct sum
    // 49 mops vs 37 mops for yield, or c.30% faster
    [Test]
    public void SingleSequenceStructForEach() {
        var sw = new Stopwatch();
        sw.Start();
        long sum = 0;
        for (var i = 0; i < 100000000; i++) {
            foreach (var single in new SingleSequence<int>(i)) {
                sum += single;
            }
        }
        sw.Stop();
        Console.WriteLine($"Elapsed {sw.ElapsedMilliseconds}");
        Console.WriteLine($"Mops {100000.0 / sw.ElapsedMilliseconds * 1.0}");
    }

IanG ma dobry post na ten temat , sugerując EnumerableFrom()jako nazwę (i wspomina, jak nazywają to Haskell i Rx Return). IIRC F # nazywa to również Return . F # Seqwzywa operatorasingleton<'T> .

Kuszące, jeśli jesteś przygotowany na koncentrację w języku C #, możesz to nazwać Yield[nawiązując do osób yield returnzaangażowanych w jego realizację].

Jeśli interesujesz się jego perfekcyjnymi aspektami, James Michael Hare ma również zwracany zero lub jeden post przedmiotów, co jest warte zeskanowania.

To może nie być nic lepszego, ale to trochę fajne:

Enumerable.Range(0, 1).Select(i => item);

Zgadzam się z komentarzami @ EarthEngine do oryginalnego postu, że „AsSingleton” to lepsza nazwa. Zobacz ten wpis w Wikipedii . Następnie z definicji singletonu wynika, że ​​jeśli wartość argumentu pustego zostanie przekazana jako argument, że „AsSingleton” powinien zwrócić IEnumerable z pojedynczą wartością null zamiast pustego IEnumerable, który rozstrzygnąłby if (item == null) yield break;debatę. Myślę, że najlepszym rozwiązaniem są dwie metody: „AsSingleton” i „AsSingletonOrEmpty”; gdzie w przypadku przekazania jako argumentu wartości null „AsSingleton” zwróci pojedynczą wartość null, a „AsSingletonOrEmpty” zwróci pustą IEnumerable. Lubię to:

public static IEnumerable<T> AsSingletonOrEmpty<T>(this T source)
{
    if (source == null)
    {
        yield break;
    }
    else
    {
        yield return source;
    }
}

public static IEnumerable<T> AsSingleton<T>(this T source)
{
    yield return source;
}

Wtedy byłyby mniej więcej analogiczne do metod rozszerzenia „First” i „FirstOrDefault” w IEnumerable, co wydaje się właściwe.

Najprostszym sposobem, który powiedziałbym, byłby new T[]{item};; nie ma do tego żadnej składni. Najbliższym odpowiednikiem, jaki mogę wymyślić, jest paramssłowo kluczowe, ale oczywiście wymaga ono dostępu do definicji metody i można go używać tylko z tablicami.

Enumerable.Range(1,1).Select(_ => {
    //Do some stuff... side effects...
    return item;
});

Powyższy kod jest użyteczny przy użyciu like

var existingOrNewObject = MyData.Where(myCondition)
       .Concat(Enumerable.Range(1,1).Select(_ => {
           //Create my object...
           return item;
       })).Take(1).First();

W powyższym fragmencie kodu nie ma sprawdzania pustego / zerowego i gwarantuje się, że zwrócony zostanie tylko jeden obiekt bez obawy wyjątków. Ponadto, ponieważ jest leniwy, zamknięcie nie zostanie wykonane, dopóki nie zostanie udowodnione, że nie ma żadnych istniejących danych spełniających kryteria.

Jestem trochę spóźniony na imprezę, ale i tak podzielę się swoją drogą. Mój problem polegał na tym, że chciałem powiązać ItemSource lub WPF TreeView z jednym obiektem. Hierarchia wygląda następująco:

Projekt> Działka (y)> Pokój (y)

Zawsze był tylko jeden projekt, ale nadal chciałem pokazać projekt w drzewie, bez konieczności przekazywania kolekcji zawierającej tylko jeden obiekt, jak sugerują niektórzy.
Ponieważ możesz przekazywać tylko obiekty IEnumerable jako ItemSource, postanowiłem uczynić moją klasę IEnumerable:

public class ProjectClass : IEnumerable<ProjectClass>
{
    private readonly SingleItemEnumerator<AufmassProjekt> enumerator;

    ... 

    public IEnumerator<ProjectClass > GetEnumerator() => this.enumerator;

    IEnumerator IEnumerable.GetEnumerator() => this.GetEnumerator();
}

I odpowiednio stwórz mojego Enumeratora:

public class SingleItemEnumerator : IEnumerator
{
    private bool hasMovedOnce;

    public SingleItemEnumerator(object current)
    {
        this.Current = current;
    }

    public bool MoveNext()
    {
        if (this.hasMovedOnce) return false;
        this.hasMovedOnce = true;
        return true;
    }

    public void Reset()
    { }

    public object Current { get; }
}

public class SingleItemEnumerator<T> : IEnumerator<T>
{
    private bool hasMovedOnce;

    public SingleItemEnumerator(T current)
    {
        this.Current = current;
    }

    public void Dispose() => (this.Current as IDisposable).Dispose();

    public bool MoveNext()
    {
        if (this.hasMovedOnce) return false;
        this.hasMovedOnce = true;
        return true;
    }

    public void Reset()
    { }

    public T Current { get; }

    object IEnumerator.Current => this.Current;
}

To chyba nie jest „najczystsze” rozwiązanie, ale dla mnie zadziałało.

EDYCJA
Aby podtrzymać zasadę pojedynczej odpowiedzialności, jak zauważył @Groo, stworzyłem nową klasę opakowań:

public class SingleItemWrapper : IEnumerable
{
    private readonly SingleItemEnumerator enumerator;

    public SingleItemWrapper(object item)
    {
        this.enumerator = new SingleItemEnumerator(item);
    }

    public object Item => this.enumerator.Current;

    public IEnumerator GetEnumerator() => this.enumerator;
}

public class SingleItemWrapper<T> : IEnumerable<T>
{
    private readonly SingleItemEnumerator<T> enumerator;

    public SingleItemWrapper(T item)
    {
        this.enumerator = new SingleItemEnumerator<T>(item);
    }

    public T Item => this.enumerator.Current;

    public IEnumerator<T> GetEnumerator() => this.enumerator;

    IEnumerator IEnumerable.GetEnumerator() => this.GetEnumerator();
}

Którego tak użyłem

TreeView.ItemSource = new SingleItemWrapper(itemToWrap);

EDYCJA 2
Poprawiłem błąd w MoveNext()metodzie.

Aby znaleźć się w rubryce „Niekoniecznie dobre rozwiązanie, ale nadal ... rozwiązanie” lub „Głupie sztuczki LINQ”, można połączyć Enumerable.Empty<>()z Enumerable.Append<>()...

IEnumerable<string> singleElementEnumerable = Enumerable.Empty<string>().Append("Hello, World!");

... lub Enumerable.Prepend<>()...

IEnumerable<string> singleElementEnumerable = Enumerable.Empty<string>().Prepend("Hello, World!");

Dwie ostatnie metody są dostępne od wersji .NET Framework 4.7.1 i .NET Core 1.0.

Jest to wykonalne rozwiązanie, jeśli jeden z nich naprawdę zdecydowani wykorzystaniem istniejących metod zamiast pisać własne, choć jestem niezdecydowany, czy jest to mniej lub bardziej wyraźne niż w Enumerable.Repeat<>()roztworze . Jest to zdecydowanie dłuższy kod (częściowo z powodu niemożności wnioskowania o parametrach typuEmpty<>() ) i tworzy jednak dwa razy więcej obiektów wyliczających.

Uzupełnienie tego „Czy wiesz, że te metody istnieją?” odpowiedź Array.Empty<>()może być zastąpiona Enumerable.Empty<>(), ale trudno argumentować, że sytuacja jest ... lepsza.

Niedawno zapytałem o to samo w innym poście ( Czy istnieje sposób na wywołanie metody C # wymagającej IEnumerable <T> z jedną wartością? ... z testem porównawczym ).

Chciałem, aby ludzie zatrzymujący się tutaj mogli zobaczyć krótkie porównanie testów porównawczych pokazane w tym nowym poście dla 4 podejść przedstawionych w tych odpowiedziach.

Wydaje się, że zwykłe wpisanie new[] { x }argumentów do metody jest najkrótszym i najszybszym rozwiązaniem.