Passando un singolo elemento come IEnumerable <T>

Esiste un modo comune per passare un singolo elemento di tipo Ta un metodo che prevede un IEnumerable<T>parametro? La lingua è C #, framework versione 2.0.

Attualmente sto usando un metodo helper (è .Net 2.0, quindi ho un sacco di metodi helper di casting / proiezione simili a LINQ), ma questo sembra sciocco:

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

Un altro modo sarebbe ovviamente quello di creare e popolare un List<T>o un Arraye passarlo invece di IEnumerable<T>.

[Modifica] Come metodo di estensione potrebbe essere chiamato:

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

Mi sto perdendo qualcosa qui?

[Modifica2] Abbiamo trovato someObject.Yield()(come suggerito da @Peter nei commenti seguenti) il nome migliore per questo metodo di estensione, principalmente per brevità, quindi eccolo insieme al commento XML se qualcuno vuole afferrarlo:

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;
    }
}

Il tuo metodo di supporto è il modo più pulito per farlo, IMO. Se passi in un elenco o in un array, un pezzo di codice senza scrupoli potrebbe lanciarlo e modificare i contenuti, portando a comportamenti strani in alcune situazioni. È possibile utilizzare una raccolta di sola lettura, ma è probabile che comporti ancora più wrapping. Penso che la tua soluzione sia accurata.

Bene, se il metodo prevede IEnumerableche devi passare qualcosa che è un elenco, anche se contiene solo un elemento.

passaggio

new[] { item }

poiché l'argomento dovrebbe essere sufficiente, penso

In C # 3.0 è possibile utilizzare la classe System.Linq.Enumerable:

// using System.Linq

Enumerable.Repeat(item, 1);

Questo creerà un nuovo IEnumerable che contiene solo il tuo articolo.

In C # 3 (so che hai detto 2), puoi scrivere un metodo di estensione generico che potrebbe rendere la sintassi un po 'più accettabile:

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

il codice client è quindi item.ToEnumerable().

Questo metodo di supporto funziona per molti articoli.

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

Sono un po 'sorpreso che nessuno abbia suggerito un nuovo sovraccarico del metodo con un argomento di tipo T per semplificare l'API client.

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

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

Ora il tuo codice client può fare solo questo:

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

o con un elenco:

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

O (come è stato precedentemente detto)

MyMethodThatExpectsAnIEnumerable(new[] { myObject });

o

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

Come nota a margine, l'ultima versione può anche essere utile se si desidera un elenco vuoto di un oggetto anonimo, ad es

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

Come ho appena scoperto, e visto anche l'utente suggerito da LukeH, un modo semplice per farlo è il seguente:

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
    }
}

Questo modello ti permetterà di chiamare la stessa funzionalità in una moltitudine di modi: un singolo oggetto; più elementi (separati da virgola); un array; una lista; un'enumerazione, ecc.

Non sono sicuro al 100% sull'efficienza dell'utilizzo del metodo AsEnumerable, ma funziona a meraviglia.

Aggiornamento: la funzione AsEnumerable sembra abbastanza efficiente! ( riferimento )

Sebbene sia eccessivo per un metodo, credo che alcune persone possano trovare utili le estensioni interattive.

Interactive Extensions (Ix) di Microsoft include il seguente metodo.

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

Che può essere utilizzato in questo modo:

var result = EnumerableEx.Return(0);

Ix aggiunge nuove funzionalità non presenti nei metodi di estensione Linq originali ed è il risultato diretto della creazione delle estensioni reattive (Rx).

Pensa, Linq Extension Methods+ Ix= Rxper IEnumerable.

Puoi trovare sia Rx che Ix su CodePlex .

È più veloce del 30% rispetto yieldo Enumerable.Repeatquando utilizzato a foreachcausa dell'ottimizzazione del compilatore C # e delle stesse prestazioni in altri casi.

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);
    }
}

in questo test:

    // 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 ha un buon post sull'argomento , suggerendo EnumerableFrom()come il nome (e menziona che Haskell e Rx lo chiamano Return). IIRC F # lo chiama anche Return . F # Seqchiama l'operatoresingleton<'T> .

Tentare di essere pronti a diventare C # -centrici è chiamarlo Yield[alludendo agli yield returninteressati nel realizzarlo].

Se sei interessato agli aspetti perfetti di questo, James Michael Hare ha uno zero di ritorno o anche un articolo che merita una scansione.

Questo potrebbe non essere migliore, ma è abbastanza bello:

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

Sono d'accordo con i commenti di @ EarthEngine al post originale, che è che "AsSingleton" è un nome migliore. Vedi questa voce di Wikipedia . Quindi dalla definizione di singleton deriva che se un valore null viene passato come argomento, "AsSingleton" dovrebbe restituire un IEnumerable con un singolo valore null invece di un IEnumerable vuoto che risolverebbe il if (item == null) yield break;dibattito. Penso che la soluzione migliore sia avere due metodi: 'AsSingleton' e 'AsSingletonOrEmpty'; dove, nel caso in cui un null venga passato come argomento, "AsSingleton" restituirà un singolo valore null e "AsSingletonOrEmpty" restituirà un IEnumerable vuoto. Come questo:

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;
}

Quindi, questi, più o meno, sarebbero analoghi ai metodi di estensione "First" e "FirstOrDefault" su IEnumerable che sembra giusto.

Il modo più semplice che direi sarebbe new T[]{item};; non c'è sintassi per farlo. L'equivalente più vicino a cui riesco a pensare è la paramsparola chiave, ma ovviamente ciò richiede che tu abbia accesso alla definizione del metodo ed è utilizzabile solo con le matrici.

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

Il codice sopra è utile quando si utilizza like

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

Nello snippet di codice sopra riportato non è presente alcun controllo vuoto / null ed è garantito che venga restituito un solo oggetto senza timore di eccezioni. Inoltre, poiché è pigro, la chiusura non verrà eseguita fino a quando non verrà dimostrato che non esistono dati adeguati ai criteri.

Sono un po 'in ritardo alla festa ma condividerò comunque la mia strada. Il mio problema era che volevo associare ItemSource o un TreeView WPF a un singolo oggetto. La gerarchia si presenta così:

Progetto> Trama (i)> Stanza (e)

Ci sarebbe sempre stato un solo progetto, ma volevo comunque mostrare il progetto nella struttura ad albero, senza dover passare una raccolta contenente solo quell'oggetto come suggerito.
Dato che puoi solo passare oggetti IEnumerable come ItemSource, ho deciso di rendere la mia classe IEnumerable:

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

    ... 

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

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

E crea il mio enumeratore di conseguenza:

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;
}

Questa probabilmente non è la soluzione "più pulita" ma ha funzionato per me.

EDIT
Per sostenere il principio della responsabilità singola, come sottolineato da @Groo, ho creato una nuova classe wrapper:

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();
}

Che ho usato così

TreeView.ItemSource = new SingleItemWrapper(itemToWrap);

EDIT 2
Ho corretto un errore con il MoveNext()metodo.

Per essere archiviato in "Non necessariamente una buona soluzione, ma comunque ... una soluzione" o "Stupidi trucchi LINQ", è possibile combinare Enumerable.Empty<>()con Enumerable.Append<>()...

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

... o Enumerable.Prepend<>()...

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

Questi ultimi due metodi sono disponibili da .NET Framework 4.7.1 e .NET Core 1.0.

Questa è una soluzione praticabile se si fosse davvero intenzionati a usare metodi esistenti invece di scriverne uno proprio, anche se sono indeciso se questo è più o meno chiaro della Enumerable.Repeat<>()soluzione . Questo codice è sicuramente più lungo (in parte a causa della deduzione dei parametri di tipo per cui non è possibile Empty<>()) e crea comunque il doppio degli oggetti enumeratore.

A completare questo "Sapevi che esistono questi metodi?" risposta, Array.Empty<>()potrebbe essere sostituito Enumerable.Empty<>(), ma è difficile discutere che renda la situazione ... migliore.

Recentemente ho chiesto la stessa cosa su un altro post ( c'è un modo per chiamare un metodo C # che richiede un IEnumerable <T> con un singolo valore? ... con benchmark ).

Volevo che le persone si fermassero qui per vedere il breve confronto comparativo mostrato in quel post più recente per 4 degli approcci presentati in queste risposte.

Sembra che semplicemente scrivere new[] { x }negli argomenti del metodo sia la soluzione più breve e veloce.