Czy istnieje lepsza alternatywa dla „włączania typu”?

Widząc, że C # nie może być switchna typie (który, jak uznaję, nie został dodany jako szczególny przypadek, ponieważ isrelacje oznaczają, że casemoże mieć zastosowanie więcej niż jedna odmiana), czy jest lepszy sposób na symulację włączenia typu innego niż ten?

void Foo(object o)
{
    if (o is A)
    {
        ((A)o).Hop();
    }
    else if (o is B)
    {
        ((B)o).Skip();
    }
    else
    {
        throw new ArgumentException("Unexpected type: " + o.GetType());
    }
}

W C # zdecydowanie brakuje przełączania typów ( AKTUALIZACJA: w C # 7 / VS 2017 włączanie typów jest obsługiwane - patrz odpowiedź Zachary'ego Yatesa poniżej ). Aby to zrobić bez dużej instrukcji if / else if / else, musisz pracować z inną strukturą. Niedługo napisałem post na blogu, w którym szczegółowo opisałem, jak zbudować strukturę TypeSwitch.

https://docs.microsoft.com/archive/blogs/jaredpar/switching-on-types

Wersja skrócona: TypeSwitch ma za zadanie zapobiegać redundantnym rzutowaniom i zapewniać składnię podobną do normalnej instrukcji switch / case. Na przykład tutaj jest TypeSwitch w akcji na standardowym zdarzeniu formularza Windows

TypeSwitch.Do(
    sender,
    TypeSwitch.Case<Button>(() => textBox1.Text = "Hit a Button"),
    TypeSwitch.Case<CheckBox>(x => textBox1.Text = "Checkbox is " + x.Checked),
    TypeSwitch.Default(() => textBox1.Text = "Not sure what is hovered over"));

Kod TypeSwitch jest w rzeczywistości dość mały i można go łatwo umieścić w projekcie.

static class TypeSwitch {
    public class CaseInfo {
        public bool IsDefault { get; set; }
        public Type Target { get; set; }
        public Action<object> Action { get; set; }
    }

    public static void Do(object source, params CaseInfo[] cases) {
        var type = source.GetType();
        foreach (var entry in cases) {
            if (entry.IsDefault || entry.Target.IsAssignableFrom(type)) {
                entry.Action(source);
                break;
            }
        }
    }

    public static CaseInfo Case<T>(Action action) {
        return new CaseInfo() {
            Action = x => action(),
            Target = typeof(T)
        };
    }

    public static CaseInfo Case<T>(Action<T> action) {
        return new CaseInfo() {
            Action = (x) => action((T)x),
            Target = typeof(T)
        };
    }

    public static CaseInfo Default(Action action) {
        return new CaseInfo() {
            Action = x => action(),
            IsDefault = true
        };
    }
}

W wersji C # 7 dostarczonej z programem Visual Studio 2017 (wydanie 15. *) możesz używać typów w caseinstrukcjach (dopasowywanie wzorca):

switch(shape)
{
    case Circle c:
        WriteLine($"circle with radius {c.Radius}");
        break;
    case Rectangle s when (s.Length == s.Height):
        WriteLine($"{s.Length} x {s.Height} square");
        break;
    case Rectangle r:
        WriteLine($"{r.Length} x {r.Height} rectangle");
        break;
    default:
        WriteLine("<unknown shape>");
        break;
    case null:
        throw new ArgumentNullException(nameof(shape));
}

W C # 6 możesz użyć instrukcji switch z operatorem nameof () (dzięki @Joey Adams):

switch(o.GetType().Name) {
    case nameof(AType):
        break;
    case nameof(BType):
        break;
}

W wersji C # 5 i wcześniejszych możesz użyć instrukcji switch, ale będziesz musiał użyć magicznego ciągu zawierającego nazwę typu ... który nie jest szczególnie przyjazny dla refaktorów (dzięki @nukefusion)

switch(o.GetType().Name) {
  case "AType":
    break;
}

Jedną z opcji jest posiadanie słownika od Typedo Action(lub innego delegata). Wyszukaj akcję na podstawie typu, a następnie wykonaj ją. Użyłem tego wcześniej do fabryk.

Z odpowiedzią JaredPara z tyłu głowy napisałem wariant jego TypeSwitchklasy, który używa wnioskowania typu dla lepszej składni:

class A { string Name { get; } }
class B : A { string LongName { get; } }
class C : A { string FullName { get; } }
class X { public string ToString(IFormatProvider provider); }
class Y { public string GetIdentifier(); }

public string GetName(object value)
{
    string name = null;
    TypeSwitch.On(value)
        .Case((C x) => name = x.FullName)
        .Case((B x) => name = x.LongName)
        .Case((A x) => name = x.Name)
        .Case((X x) => name = x.ToString(CultureInfo.CurrentCulture))
        .Case((Y x) => name = x.GetIdentifier())
        .Default((x) => name = x.ToString());
    return name;
}

Pamiętaj, że kolejność Case()metod jest ważna.

Uzyskaj pełny i skomentowany kod dla mojej TypeSwitchklasy . To jest działająca wersja skrócona:

public static class TypeSwitch
{
    public static Switch<TSource> On<TSource>(TSource value)
    {
        return new Switch<TSource>(value);
    }

    public sealed class Switch<TSource>
    {
        private readonly TSource value;
        private bool handled = false;

        internal Switch(TSource value)
        {
            this.value = value;
        }

        public Switch<TSource> Case<TTarget>(Action<TTarget> action)
            where TTarget : TSource
        {
            if (!this.handled && this.value is TTarget)
            {
                action((TTarget) this.value);
                this.handled = true;
            }
            return this;
        }

        public void Default(Action<TSource> action)
        {
            if (!this.handled)
                action(this.value);
        }
    }
}

Utwórz nadklasę (S) i odziedzicz po niej A i B. Następnie zadeklaruj abstrakcyjną metodę na S, którą każda podklasa musi zaimplementować.

Robiąc to, metoda „foo” może również zmienić swój podpis na Foo (S o), dzięki czemu jest bezpieczny i nie musisz rzucać tego brzydkiego wyjątku.

Możesz użyć dopasowania wzorca w C # 7 lub nowszej:

switch (foo.GetType())
{
    case var type when type == typeof(Player):
        break;
    case var type when type == typeof(Address):
        break;
    case var type when type == typeof(Department):
        break;
    case var type when type == typeof(ContactType):
        break;
    default:
        break;
}

Naprawdę powinieneś przeciążać swoją metodę, nie próbując samemu ujednoznacznić. Większość dotychczasowych odpowiedzi nie uwzględnia przyszłych podklas, co może później prowadzić do naprawdę strasznych problemów z obsługą.

Jeśli korzystasz z C # 4, możesz skorzystać z nowej dynamicznej funkcjonalności, aby uzyskać interesującą alternatywę. Nie twierdzę, że tak jest lepiej, w rzeczywistości wydaje się bardzo prawdopodobne, że będzie wolniejszy, ale ma w sobie pewną elegancję.

class Thing
{

  void Foo(A a)
  {
     a.Hop();
  }

  void Foo(B b)
  {
     b.Skip();
  }

}

A użycie:

object aOrB = Get_AOrB();
Thing t = GetThing();
((dynamic)t).Foo(aorB);

Powodem tego jest fakt, że wywołanie metody dynamicznej w języku C # 4 zostało rozwiązane w czasie wykonywania zamiast w czasie kompilacji. Niedawno napisałem nieco więcej o tym pomyśle . Ponownie chciałbym tylko powtórzyć, że to prawdopodobnie działa gorzej niż wszystkie inne sugestie, oferuję to po prostu jako ciekawość.

Tak, dzięki C # 7, który można osiągnąć. Oto jak to się robi (używając wzorca wyrażenia ):

switch (o)
{
    case A a:
        a.Hop();
        break;
    case B b:
        b.Skip();
        break;
    case C _: 
        return new ArgumentException("Type C will be supported in the next version");
    default:
        return new ArgumentException("Unexpected type: " + o.GetType());
}

W przypadku typów wbudowanych można użyć wyliczenia TypeCode. Należy pamiętać, że GetType () jest dość powolny, ale prawdopodobnie nie jest istotny w większości sytuacji.

switch (Type.GetTypeCode(someObject.GetType()))
{
    case TypeCode.Boolean:
        break;
    case TypeCode.Byte:
        break;
    case TypeCode.Char:
        break;
}

Dla niestandardowych typów możesz utworzyć własne wyliczenie oraz interfejs lub klasę podstawową z abstrakcyjną właściwością lub metodą ...

Implementacja własności klasy abstrakcyjnej

public enum FooTypes { FooFighter, AbbreviatedFool, Fubar, Fugu };
public abstract class Foo
{
    public abstract FooTypes FooType { get; }
}
public class FooFighter : Foo
{
    public override FooTypes FooType { get { return FooTypes.FooFighter; } }
}

Implementacja metody klasy abstrakcyjnej

public enum FooTypes { FooFighter, AbbreviatedFool, Fubar, Fugu };
public abstract class Foo
{
    public abstract FooTypes GetFooType();
}
public class FooFighter : Foo
{
    public override FooTypes GetFooType() { return FooTypes.FooFighter; }
}

Implementacja interfejsu własności

public enum FooTypes { FooFighter, AbbreviatedFool, Fubar, Fugu };
public interface IFooType
{
    FooTypes FooType { get; }
}
public class FooFighter : IFooType
{
    public FooTypes FooType { get { return FooTypes.FooFighter; } }
}

Implementacja metody interfejsu

public enum FooTypes { FooFighter, AbbreviatedFool, Fubar, Fugu };
public interface IFooType
{
    FooTypes GetFooType();
}
public class FooFighter : IFooType
{
    public FooTypes GetFooType() { return FooTypes.FooFighter; }
}

Jeden z moich współpracowników właśnie mi o tym powiedział: ma tę zaletę, że można go używać do dosłownie każdego rodzaju obiektu, nie tylko tych, które zdefiniujesz. Ma tę wadę, że jest nieco większy i wolniejszy.

Najpierw zdefiniuj klasę statyczną w następujący sposób:

public static class TypeEnumerator
{
    public class TypeEnumeratorException : Exception
    {
        public Type unknownType { get; private set; }
        public TypeEnumeratorException(Type unknownType) : base()
        {
            this.unknownType = unknownType;
        }
    }
    public enum TypeEnumeratorTypes { _int, _string, _Foo, _TcpClient, };
    private static Dictionary<Type, TypeEnumeratorTypes> typeDict;
    static TypeEnumerator()
    {
        typeDict = new Dictionary<Type, TypeEnumeratorTypes>();
        typeDict[typeof(int)] = TypeEnumeratorTypes._int;
        typeDict[typeof(string)] = TypeEnumeratorTypes._string;
        typeDict[typeof(Foo)] = TypeEnumeratorTypes._Foo;
        typeDict[typeof(System.Net.Sockets.TcpClient)] = TypeEnumeratorTypes._TcpClient;
    }
    /// <summary>
    /// Throws NullReferenceException and TypeEnumeratorException</summary>
    /// <exception cref="System.NullReferenceException">NullReferenceException</exception>
    /// <exception cref="MyProject.TypeEnumerator.TypeEnumeratorException">TypeEnumeratorException</exception>
    public static TypeEnumeratorTypes EnumerateType(object theObject)
    {
        try
        {
            return typeDict[theObject.GetType()];
        }
        catch (KeyNotFoundException)
        {
            throw new TypeEnumeratorException(theObject.GetType());
        }
    }
}

A potem możesz użyć tego w następujący sposób:

switch (TypeEnumerator.EnumerateType(someObject))
{
    case TypeEnumerator.TypeEnumeratorTypes._int:
        break;
    case TypeEnumerator.TypeEnumeratorTypes._string:
        break;
}

Podobało mi się użycie przez Virtlink pisania niejawnego, aby uczynić przełącznik znacznie bardziej czytelnym, ale nie podobało mi się, że wczesne wyjście nie jest możliwe i że dokonujemy alokacji. Podkręćmy trochę perf.

public static class TypeSwitch
{
    public static void On<TV, T1>(TV value, Action<T1> action1)
        where T1 : TV
    {
        if (value is T1) action1((T1)value);
    }

    public static void On<TV, T1, T2>(TV value, Action<T1> action1, Action<T2> action2)
        where T1 : TV where T2 : TV
    {
        if (value is T1) action1((T1)value);
        else if (value is T2) action2((T2)value);
    }

    public static void On<TV, T1, T2, T3>(TV value, Action<T1> action1, Action<T2> action2, Action<T3> action3)
        where T1 : TV where T2 : TV where T3 : TV
    {
        if (value is T1) action1((T1)value);
        else if (value is T2) action2((T2)value);
        else if (value is T3) action3((T3)value);
    }

    // ... etc.
}

Cóż, to mnie boli. Zróbmy to w T4:

<#@ template debug="false" hostSpecific="true" language="C#" #>
<#@ output extension=".cs" #>
<#@ Assembly Name="System.Core.dll" #>
<#@ import namespace="System.Linq" #> 
<#@ import namespace="System.IO" #> 
<#
    string GenWarning = "// THIS FILE IS GENERATED FROM " + Path.GetFileName(Host.TemplateFile) + " - ANY HAND EDITS WILL BE LOST!";
    const int MaxCases = 15;
#>
<#=GenWarning#>

using System;

public static class TypeSwitch
{
<# for(int icase = 1; icase <= MaxCases; ++icase) {
    var types = string.Join(", ", Enumerable.Range(1, icase).Select(i => "T" + i));
    var actions = string.Join(", ", Enumerable.Range(1, icase).Select(i => string.Format("Action<T{0}> action{0}", i)));
    var wheres = string.Join(" ", Enumerable.Range(1, icase).Select(i => string.Format("where T{0} : TV", i)));
#>
    <#=GenWarning#>

    public static void On<TV, <#=types#>>(TV value, <#=actions#>)
        <#=wheres#>
    {
        if (value is T1) action1((T1)value);
<# for(int i = 2; i <= icase; ++i) { #>
        else if (value is T<#=i#>) action<#=i#>((T<#=i#>)value);
<#}#>
    }

<#}#>
    <#=GenWarning#>
}

Trochę zmieniając przykład Virtlink:

TypeSwitch.On(operand,
    (C x) => name = x.FullName,
    (B x) => name = x.LongName,
    (A x) => name = x.Name,
    (X x) => name = x.ToString(CultureInfo.CurrentCulture),
    (Y x) => name = x.GetIdentifier(),
    (object x) => name = x.ToString());

Czytelny i szybki. Teraz, jak wszyscy wskazują w swoich odpowiedziach i biorąc pod uwagę naturę tego pytania, kolejność jest ważna w dopasowywaniu typów. W związku z tym:

• Najpierw umieść typy liści, później typy podstawowe.
• W przypadku typów równorzędnych najpierw stawiaj bardziej prawdopodobne dopasowania, aby zmaksymalizować perf.
• Oznacza to, że nie ma potrzeby specjalnego domyślnego przypadku. Zamiast tego po prostu użyj najbardziej bazowego typu w lambda i umieść go na końcu.

Biorąc pod uwagę, że dziedziczenie ułatwia rozpoznanie obiektu jako więcej niż jednego typu, myślę, że zmiana może prowadzić do złej dwuznaczności. Na przykład:

Przypadek 1

{
  string s = "a";
  if (s is string) Print("Foo");
  else if (s is object) Print("Bar");
}

Przypadek 2

{
  string s = "a";
  if (s is object) Print("Foo");
  else if (s is string) Print("Bar");
}

Ponieważ s jest ciągiem i obiektem. Myślę, że kiedy piszesz switch(foo), oczekujesz, że foo będzie pasowało do jednego i tylko jednegocase stwierdzeń. Po włączeniu typów kolejność pisania instrukcji case może zmienić wynik całej instrukcji switch. Myślę, że to byłoby złe.

Można pomyśleć o sprawdzeniu kompilatora typów instrukcji „typwitch”, sprawdzeniu, czy wyliczone typy nie dziedziczą po sobie. To jednak nie istnieje.

foo is Tto nie to samo co foo.GetType() == typeof(T)!!

Ja też bym

• użyj metody przeciążenia (podobnie jak x0n ) lub
• użyj podklas (tak jak Pablo ) lub
• zastosuj wzór gościa .

Innym sposobem byłoby zdefiniowanie interfejsu IThing, a następnie zaimplementowanie go w obu klasach, oto fragment kodu:

public interface IThing
{
    void Move();
}

public class ThingA : IThing
{
    public void Move()
    {
        Hop();
    }

    public void Hop(){  
        //Implementation of Hop 
    }

}

public class ThingA : IThing
{
    public void Move()
    {
        Skip();
    }

    public void Skip(){ 
        //Implementation of Skip    
    }

}

public class Foo
{
    static void Main(String[] args)
    {

    }

    private void Foo(IThing a)
    {
        a.Move();
    }
}

Jak na C # 7.0 specyfikacji, można zadeklarować zmienną lokalną scoped w sposób casetematyce switch:

object a = "Hello world";
switch (a)
{
    case string myString:
        // The variable 'a' is a string!
        break;
    case int myInt:
        // The variable 'a' is an int!
        break;
    case Foo myFoo:
        // The variable 'a' is of type Foo!
        break;
}

Jest to najlepszy sposób na zrobienie czegoś takiego, ponieważ obejmuje po prostu rzutowanie i operacje push-on-the-stack, które są najszybszymi operacjami, jakie interpreter może wykonać tuż po bitowych operacjach i booleanwarunkach.

Porównując to do Dictionary<K, V>, tutaj jest o wiele mniejsze zużycie pamięci: trzymanie słownika wymaga więcej miejsca w pamięci RAM i trochę więcej obliczeń przez procesor do utworzenia dwóch tablic (jednej dla kluczy, a drugiej dla wartości) i zebrania kodów mieszających dla kluczy do umieszczenia wartości do odpowiednich kluczy.

Tak więc, o ile wiem, nie sądzę, aby istniał szybszy sposób, chyba że chcesz użyć tylko if- then- elsebloku z isoperatorem w następujący sposób:

object a = "Hello world";
if (a is string)
{
    // The variable 'a' is a string!
} else if (a is int)
{
    // The variable 'a' is an int!
} // etc.

Możesz tworzyć przeciążone metody:

void Foo(A a) 
{ 
    a.Hop(); 
}

void Foo(B b) 
{ 
    b.Skip(); 
}

void Foo(object o) 
{ 
    throw new ArgumentException("Unexpected type: " + o.GetType()); 
}

I rzuć argument, aby dynamicwpisać, aby ominąć sprawdzanie typu statycznego:

Foo((dynamic)something);

Udoskonalenia dopasowania wzoru w języku C # 8 umożliwiły to w ten sposób. W niektórych przypadkach spełnia swoje zadanie i jest bardziej zwięzły.

        public Animal Animal { get; set; }
        ...
        var animalName = Animal switch
        {
            Cat cat => "Tom",
            Mouse mouse => "Jerry",
            _ => "unknown"
        };

Szukasz Discriminated Unionsfunkcji języka F #, ale możesz osiągnąć podobny efekt, korzystając z utworzonej przeze mnie biblioteki OneOf

https://github.com/mcintyre321/OneOf

Główną zaletą w stosunku do switch(a if, a exceptions as control flow) jest to, że podczas kompilacji bezpieczny - nie ma domyślnego obsługi lub nie mieści się

void Foo(OneOf<A, B> o)
{
    o.Switch(
        a => a.Hop(),
        b => b.Skip()
    );
}

Jeśli dodasz trzeci element do o, pojawi się błąd kompilatora, ponieważ musisz dodać funkcję obsługi Func w wywołaniu przełącznika.

Możesz także wykonać polecenie, .Matchktóre zwraca wartość, zamiast wykonać instrukcję:

double Area(OneOf<Square, Circle> o)
{
    return o.Match(
        square => square.Length * square.Length,
        circle => Math.PI * circle.Radius * circle.Radius
    );
}

Utwórz interfejs IFooable, a następnie spraw , aby twoja Ai Bklasy zaimplementowały wspólną metodę, która z kolei wywołuje odpowiednią metodę, którą chcesz:

interface IFooable
{
    public void Foo();
}

class A : IFooable
{
    //other methods ...

    public void Foo()
    {
        this.Hop();
    }
}

class B : IFooable
{
    //other methods ...

    public void Foo()
    {
        this.Skip();
    }
}

class ProcessingClass
{
    public void Foo(object o)
    {
        if (o == null)
            throw new NullRefferenceException("Null reference", "o");

        IFooable f = o as IFooable;
        if (f != null)
        {
            f.Foo();
        }
        else
        {
            throw new ArgumentException("Unexpected type: " + o.GetType());
        }
    }
}

Zauważ, że lepiej jest użyć aszamiast tego najpierw sprawdzania za pomocą, isa następnie rzucania, ponieważ w ten sposób wykonujesz 2 rzuty, więc jest to droższe.

W takich przypadkach zwykle kończę na liście predykatów i działań. Coś w tym stylu:

class Mine {
    static List<Func<object, bool>> predicates;
    static List<Action<object>> actions;

    static Mine() {
        AddAction<A>(o => o.Hop());
        AddAction<B>(o => o.Skip());
    }

    static void AddAction<T>(Action<T> action) {
        predicates.Add(o => o is T);
        actions.Add(o => action((T)o);
    }

    static void RunAction(object o) {
        for (int i=0; o < predicates.Count; i++) {
            if (predicates[i](o)) {
                actions[i](o);
                break;
            }
        }
    }

    void Foo(object o) {
        RunAction(o);
    }
}

Po porównaniu opcji przedstawionych tutaj w odpowiedzi na kilka funkcji F #, odkryłem, że F # ma znacznie lepszą obsługę przełączania opartego na typach (chociaż nadal trzymam się C #).
Możesz chcieć zobaczyć tu i tutaj .

Stworzyłbym interfejs z dowolną nazwą i nazwą metody, która miałaby sens dla twojego przełącznika, nazwijmy je odpowiednio: IDoableto mówi o implementacji void Do().

public interface IDoable
{
    void Do();
}

public class A : IDoable
{
    public void Hop() 
    {
        // ...
    }

    public void Do()
    {
        Hop();
    }
}

public class B : IDoable
{
    public void Skip() 
    {
        // ...
    }

    public void Do()
    {
        Skip();
    }
}

i zmień metodę w następujący sposób:

void Foo<T>(T obj)
    where T : IDoable
{
    // ...
    obj.Do();
    // ...
}

Przynajmniej jesteś bezpieczny w czasie kompilacji i podejrzewam, że pod względem wydajności jest to lepsze niż sprawdzanie typu w czasie wykonywania.

Od C # 8 możesz sprawić, że będzie jeszcze bardziej zwięzły dzięki nowemu przełącznikowi. Za pomocą opcji discard _ można uniknąć tworzenia niepotrzebnych zmiennych, gdy nie są potrzebne, na przykład:

        return document switch {
            Invoice _ => "Is Invoice",
            ShippingList _ => "Is Shipping List",
            _ => "Unknown"
        };

Faktura i lista wysyłkowa to klasy, a dokument to obiekt, którym może być dowolna z nich.

Zgadzam się z Jonem w kwestii posiadania skrótu akcji do nazwy klasy. Jeśli utrzymasz swój wzorzec, możesz zamiast tego rozważyć użycie konstrukcji „as”:

A a = o as A;
if (a != null) {
    a.Hop();
    return;
}
B b = o as B;
if (b != null) {
    b.Skip();
    return;
}
throw new ArgumentException("...");

Różnica polega na tym, że gdy używasz tupotu, jeśli (foo to Bar) {((Bar) foo) .Action (); } wykonujesz rzut typu dwa razy. Teraz może kompilator zoptymalizuje i wykona tę pracę tylko raz - ale nie liczyłbym na to.

Jak sugeruje Pablo, podejście do interfejsu jest prawie zawsze właściwe, aby sobie z tym poradzić. Aby naprawdę skorzystać z przełącznika, inną alternatywą jest posiadanie niestandardowego wyliczenia oznaczającego twój typ na zajęciach.

enum ObjectType { A, B, Default }

interface IIdentifiable
{
    ObjectType Type { get; };
}
class A : IIdentifiable
{
    public ObjectType Type { get { return ObjectType.A; } }
}

class B : IIdentifiable
{
    public ObjectType Type { get { return ObjectType.B; } }
}

void Foo(IIdentifiable o)
{
    switch (o.Type)
    {
        case ObjectType.A:
        case ObjectType.B:
        //......
    }
}

Jest to również zaimplementowane w BCL. Jednym z przykładów jest MemberInfo.MemberTypes , innym jest GetTypeCodedla typów pierwotnych, takich jak:

void Foo(object o)
{
    switch (Type.GetTypeCode(o.GetType())) // for IConvertible, just o.GetTypeCode()
    {
        case TypeCode.Int16:
        case TypeCode.Int32:
        //etc ......
    }
}

To jest alternatywna odpowiedź, która łączy wkłady z odpowiedzi JaredPar i VirtLink, z następującymi ograniczeniami:

• Konstrukcja przełącznika zachowuje się jak funkcja i odbiera funkcje jako parametry do spraw.
• Zapewnia, że ​​jest poprawnie zbudowany i zawsze istnieje funkcja domyślna .
• To wraca po pierwszym meczu (true dla JaredPar odpowiedź, nie jest prawdą dla VirtLink jeden).

Stosowanie:

 var result = 
   TSwitch<string>
     .On(val)
     .Case((string x) => "is a string")
     .Case((long x) => "is a long")
     .Default(_ => "what is it?");

Kod:

public class TSwitch<TResult>
{
    class CaseInfo<T>
    {
        public Type Target { get; set; }
        public Func<object, T> Func { get; set; }
    }

    private object _source;
    private List<CaseInfo<TResult>> _cases;

    public static TSwitch<TResult> On(object source)
    {
        return new TSwitch<TResult> { 
            _source = source,
            _cases = new List<CaseInfo<TResult>>()
        };
    }

    public TResult Default(Func<object, TResult> defaultFunc)
    {
        var srcType = _source.GetType();
       foreach (var entry in _cases)
            if (entry.Target.IsAssignableFrom(srcType))
                return entry.Func(_source);

        return defaultFunc(_source);
    }

    public TSwitch<TResult> Case<TSource>(Func<TSource, TResult> func)
    {
        _cases.Add(new CaseInfo<TResult>
        {
            Func = x => func((TSource)x),
            Target = typeof(TSource)
        });
        return this;
    }
}

Tak - wystarczy użyć nieco dziwnie nazwanego „dopasowania wzorca” od C # 7 w górę, aby dopasować klasę lub strukturę:

IObject concrete1 = new ObjectImplementation1();
IObject concrete2 = new ObjectImplementation2();

switch (concrete1)
{
    case ObjectImplementation1 c1: return "type 1";         
    case ObjectImplementation2 c2: return "type 2";         
}

używam

    public T Store<T>()
    {
        Type t = typeof(T);

        if (t == typeof(CategoryDataStore))
            return (T)DependencyService.Get<IDataStore<ItemCategory>>();
        else
            return default(T);
    }

Powinien współpracować z

rodzaj sprawy _:

lubić:

int i = 1;
bool b = true;
double d = 1.1;
object o = i; // whatever you want

switch (o)
{
    case int _:
        Answer.Content = "You got the int";
        break;
    case double _:
        Answer.Content = "You got the double";
        break;
    case bool _:
        Answer.Content = "You got the bool";
        break;
}

Jeśli znasz klasę, której oczekujesz, ale nadal nie masz obiektu, możesz to zrobić:

private string GetAcceptButtonText<T>() where T : BaseClass, new()
{
    switch (new T())
    {
        case BaseClassReview _: return "Review";
        case BaseClassValidate _: return "Validate";
        case BaseClassAcknowledge _: return "Acknowledge";
        default: return "Accept";
    }
}