Obejście problemu z powodu braku kowariancji typu powrotu przy zastępowaniu metod wirtualnych

Question

Czy istnieje sposób na "hakowanie" lub "przymus" korektorów kowariancyjnych w C#?

Na przykład:

public class Alpha { 
    public virtual Alpha DoSomething() { 
     return AlphaFactory.GetAlphaFromSomewhere(); 
    } 
} 
public class Beta : Alpha { 
    public override Beta DoSomething() { 
     return BetaFactory.GetBetaFromSomewhere(); 
    } 
} 

Niestety, C# nie obsługuje tej funkcji (co wydaje się nieco śmieszne, ale to ani tu ani tam).

Myślałem, że mam odpowiedź metodą ukrycia:

new public Beta DoSomething() { 
    return BetaFactory.GetBetaFromSomewhere(); 
} 

Ale to nie dodać wpis w do „vtable”, to po prostu w zasadzie deklaruje nową metodę o tej samej nazwie, i jako taki oznacza, że ​​dostęp do Beta s przez wskaźnik do Alpha wywoła Alpha.DoSomething().

A więc jakieś dobre sztuczki?

Answer 1

Możesz zrobić całkiem niezłe rzeczy z rodzajami.

public class Alpha<T> where T: Alpha<T> { 
    public virtual T DoSomething() { 
     throw new NotImplementedException(); 
    } 
} 
public class Beta : Alpha<Beta> { 
    public override Beta DoSomething() { 
     throw new NotImplementedException(); 
    } 
} 

Answer 2

W większości przypadków nie ma dużych korzyści w przypadku kowariancji zwrotu.

Jeśli dzwonisz wirtualny Alpha.DoSomething to naprawdę nie wiem, czy wracają się Alpha lub grupę Beta tak jak ma typ kowariancji pomocy powrócić? Będziesz musiał zapisać wynik w typowym obiekcie Alpha, ponieważ jest to jedyny typ, który może przyznać Alpha s lub Beta s.

Z drugiej strony, jeśli statycznie wiedzieć że dzwonisz Beta.DoSomething następnie można albo: bezpośrednio użyć zwrócony Alpha wpisane obiektu, ponieważ będzie dostępu do wspólnych metod funkcjonalności lub wirtualne więc nie obchodzi mnie, czy to naprawdę Beta (połączenie wirtualne zostanie ustawione na prawidłowy typ) lub można bezpośrednio wybrać (bezpieczny w czasie wykonywania) rzutowany na Beta w celu uzyskania dostępu do konkretnej implementacji.

Edytuj: usunięto problem z bezpiecznym typem. Ledwo to przemyślałem i ewidentnie powrót kowariancji typu byłby bezpieczny. Reszta odpowiedzi stoi jednak. Nie mogę znaleźć nic szczególnie interesującego w tej funkcji, przynajmniej w taki sposób, w jaki OP chce z niej skorzystać: uniknąć bezpiecznego taniego rzucenia?

Answer 3

Zawsze można zawinąć metodę wewnątrz innej metody

public class Alpha { 
    public virtual Alpha DoSomething() { 
     return AlphaFactory.GetAlphaFromSomewhere(); 
    } 
} 
public class Beta : Alpha { 
    private Beta Helper() { 
     return BetaFactory.GetBetaFromSomewhere(); 
    } 
    public Beta DoSomething() { 
     return Helper(); 
    } 
    public override Alpha DoSomething() { 
     return Helper(); 
    } 
} 

Jeśli istnieje wiele metod, choć może chcesz autogenerować te owijarki. Jeśli to zbyt wymagające, rozwiązanie @recursive jest wszystkim, co zostało.