Jakie jest właściwe zastosowanie downcastingu?

Downcasting oznacza rzutowanie z klasy podstawowej (lub interfejsu) do podklasy lub klasy liścia.

Przykładem downcast może być rzutowanie z System.Objectinnego typu.

Downcasting jest niepopularny, może pachnie kodem: doktryna obiektowa preferuje na przykład definiowanie i wywoływanie metod wirtualnych lub abstrakcyjnych zamiast downcastingu.

• Jakie, jeśli w ogóle, są dobre i właściwe przypadki użycia dla downcastingu? To znaczy, w jakich okolicznościach należy pisać kod, który jest w dół?
• Jeśli twoja odpowiedź brzmi „brak”, to dlaczego język obsługuje downcasting?

Oto niektóre właściwe zastosowania downcastingu.

I szacunkiem stanowczo nie zgadzają się z innymi, którzy mówią tu zastosowanie downcasts jest zdecydowanie zapach kod, ponieważ wierzę, nie ma innego rozsądny sposób na rozwiązanie odpowiednie problemy.

Equals:

class A
{
    // Nothing here, but if you're a C++ programmer who dislikes object.Equals(object),
    // pretend it's not there and we have abstract bool A.Equals(A) instead.
}
class B : A
{
    private int x;
    public override bool Equals(object other)
    {
        var casted = other as B;  // cautious downcast (dynamic_cast in C++)
        return casted != null && this.x == casted.x;
    }
}

Clone:

class A : ICloneable
{
    // Again, if you dislike ICloneable, that's not the point.
    // Just ignore that and pretend this method returns type A instead of object.
    public virtual object Clone()
    {
        return this.MemberwiseClone();  // some sane default behavior, whatever
    }
}
class B : A
{
    private int[] x;
    public override object Clone()
    {
        var copy = (B)base.Clone();  // known downcast (static_cast in C++)
        copy.x = (int[])this.x.Clone();  // oh hey, another downcast!!
        return copy;
    }
}

Stream.EndRead/Write:

class MyStream : Stream
{
    private class AsyncResult : IAsyncResult
    {
        // ...
    }
    public override int EndRead(IAsyncResult other)
    {
        return Blah((AsyncResult)other);  // another downcast (likely ~static_cast)
    }
}

Jeśli chcesz powiedzieć, że są to zapachy kodowe, musisz zapewnić im lepsze rozwiązania (nawet jeśli można ich uniknąć z powodu niedogodności). Nie wierzę, że istnieją lepsze rozwiązania.

Downcasting jest niepopularny, może zapach kodu

Nie zgadzam się. Downcasting jest niezwykle popularny ; ogromna liczba programów w świecie rzeczywistym zawiera co najmniej jeden problem. I to może nie jest zapach kodu. To zdecydowanie zapach kodu. Dlatego operacja downcastingu musi być zamanifestowana w tekście programu . Dzięki temu łatwiej jest zauważyć zapach i poświęcić mu uwagę na przeglądanie kodu.

w jakich okolicznościach należy napisać kod, który nie działa?

W każdych okolicznościach, gdy:

• masz w 100% poprawną wiedzę o fakcie dotyczącym typu środowiska wykonawczego wyrażenia, które jest bardziej szczegółowe niż typ wyrażenia w czasie kompilacji, oraz
• musisz skorzystać z tego faktu, aby skorzystać z możliwości obiektu niedostępnego w typie kompilacji oraz
• lepsze wykorzystanie czasu i wysiłku na napisanie obsady, niż refaktoryzacja programu w celu wyeliminowania jednego z dwóch pierwszych punktów.

Jeśli możesz tanio refaktoryzować program, tak aby kompilator mógł wydedukować typ środowiska wykonawczego, lub refaktoryzować program, aby nie trzeba było możliwości bardziej pochodnego typu, zrób to. Do języka dodano downcasty w tych okolicznościach, w których refaktoryzacja programu jest trudna i droga .

dlaczego język obsługuje downcasting?

C # został wymyślony przez pragmatycznych programistów, którzy mają zadania do wykonania, dla pragmatycznych programistów, którzy mają zadania do wykonania. Projektanci C # nie są purystami OO. A system typu C # nie jest idealny; z założenia nie docenia ograniczeń, które można nałożyć na typ środowiska wykonawczego zmiennej.

Również downcasting jest bardzo bezpieczny w C #. Mamy silną gwarancję, że downcast zostanie zweryfikowany w czasie wykonywania, a jeśli nie będzie można go zweryfikować, program wykona właściwą czynność i ulegnie awarii. To jest cudowne; oznacza to, że jeśli twoje 100% poprawne zrozumienie semantyki typów okaże się 99,99% poprawne, to twój program działa przez 99,99% czasu i zawiesza resztę czasu, zamiast zachowywać się nieprzewidywalnie i uszkadzać dane użytkownika 0,01% czasu .

ĆWICZENIE: Istnieje co najmniej jeden sposób na utworzenie downcastu w języku C # bez użycia jawnego operatora rzutowania. Czy możesz wymyślić takie scenariusze? Ponieważ są to również potencjalne zapachy kodu, jakie według Pana czynniki projektowe przyczyniły się do zaprojektowania funkcji, która może spowodować awarię w dół, bez manifestu w kodzie?

Procedury obsługi zdarzeń zwykle mają podpis MethodName(object sender, EventArgs e). W niektórych przypadkach można obsłużyć zdarzenie bez względu na typ sender, a nawet w ogóle go nie używać sender, ale w innych sendernależy obsłużyć bardziej konkretny typ, aby obsłużyć zdarzenie.

Na przykład możesz mieć dwa TextBoxs i chcesz użyć jednego delegata do obsługi zdarzenia z każdego z nich. Następnie musisz rzutować senderna TextBox, aby uzyskać dostęp do niezbędnych właściwości do obsługi zdarzenia:

private void TextBox_TextChanged(object sender, EventArgs e)
{
   TextBox box = (TextBox)sender;
   box.BackColor = string.IsNullOrEmpty(box.Text) ? Color.Red : Color.White;
}

Tak, w tym przykładzie możesz utworzyć własną podklasę, TextBoxktóra zrobiła to wewnętrznie. Jednak nie zawsze jest to praktyczne lub możliwe.

Potrzebujesz downcastingu, gdy coś daje ci nadtyp i musisz postępować inaczej w zależności od podtypu.

decimal value;
Donation d = user.getDonation();
if (d is CashDonation) {
     value = ((CashDonation)d).getValue();
}
if (d is ItemDonation) {
     value = itemValueEstimator.estimateValueOf(((ItemDonation)d).getItem());
}
System.out.println("Thank you for your generous donation of $" + value);

Nie, to nie pachnie dobrze. W idealnym świecie Donationistniałaby abstrakcyjna metoda, getValuea każdy podtyp implementujący miałby odpowiednią implementację.

Ale co, jeśli te klasy pochodzą z biblioteki, której nie możesz lub nie chcesz zmieniać? Wtedy nie ma innej opcji.

Aby dodać do odpowiedzi Erica Lipperta, ponieważ nie mogę komentować ...

Często można uniknąć downcastingu, refaktoryzując interfejs API w celu użycia ogólnych. Ale generyczne nie zostały dodane do języka aż do wersji 2.0 . Więc nawet jeśli twój własny kod nie musi obsługiwać starożytnych wersji językowych, możesz użyć starszych klas, które nie są sparametryzowane. Na przykład, można zdefiniować pewną klasę do przenoszenia ładunku typu Object, który musisz rzucić na typ, o którym wiesz, że tak naprawdę jest.

Istnieje kompromis między językami statycznymi i dynamicznie typowanymi. Wpisywanie statyczne daje kompilatorowi wiele informacji, dzięki którym można uzyskać dość silne gwarancje bezpieczeństwa (części) programów. Jest to jednak kosztowne, ponieważ nie tylko musisz wiedzieć, że twój program jest poprawny, ale musisz napisać odpowiedni kod, aby przekonać kompilator, że tak jest. Innymi słowy, zgłaszanie roszczeń jest łatwiejsze niż ich udowodnienie.

Istnieją „niebezpieczne” konstrukcje, które pomagają w tworzeniu niepotwierdzonych twierdzeń dotyczących kompilatora. Na przykład bezwarunkowe wezwania do Nullable.Value, bezwarunkowe sprowadzenia, dynamicobiekty itp. Pozwalają one na dochodzenie roszczenia („Twierdzę, że obiekt ajest String, jeśli się mylę, rzucają InvalidCastException”) bez konieczności jego udowodnienia. Może to być przydatne w przypadkach, gdy udowodnienie, że jest to znacznie trudniejsze niż opłacalne.

Nadużywanie tego jest ryzykowne i właśnie dlatego istnieje wyraźna notacja w dół i jest obowiązkowa; to sól syntaktyczna, która ma zwrócić uwagę na niebezpieczną operację. Język mógł zostać zaimplementowany z niejawnym downcastingiem (gdzie wywnioskowany typ jest jednoznaczny), ale to ukryłoby tę niebezpieczną operację, co nie jest pożądane.

Downcasting jest uważany za zły z kilku powodów. Przede wszystkim myślę, ponieważ jest to anty-OOP.

OOP naprawdę by się to spodobało, gdybyś nigdy nie musiał być przygnębiony, ponieważ jego „raison-d'etre” polega na tym, że polimorfizm oznacza, że ​​nie musisz iść

if(object is X)
{
    //do the thing we do with X's
}
else
{
    //of the thing we do with Y's
}

po prostu to robisz

x.DoThing()

a kod auto-magicznie robi właściwą rzecz.

Istnieje kilka „trudnych” powodów, aby nie spuszczać:

• W C ++ jest wolny.
• Jeśli wybierzesz niewłaściwy typ, pojawi się błąd czasu wykonywania.

Ale alternatywa dla downcastingu w niektórych scenariuszach może być dość brzydka.

Klasycznym przykładem jest przetwarzanie komunikatów, w którym nie chcesz dodawać funkcji przetwarzania do obiektu, ale przechowywać go w procesorze komunikatów. Następnie mam MessageBaseClassdo przetworzenia tonę w tablicy, ale do poprawnego przetwarzania potrzebuję każdej z nich według podtypu.

Możesz użyć Double Dispatch, aby obejść problem ( https://en.wikipedia.org/wiki/Double_dispatch ) ... Ale to też ma swoje problemy. Lub możesz po prostu sprowadzić prosty kod na ryzyko tych trudnych powodów.

Ale to było zanim wynaleziono Generics. Teraz możesz uniknąć downcastingu, podając typ, w którym szczegóły zostaną określone później.

MessageProccesor<T> może zmieniać parametry metody i zwracane wartości o określony typ, ale nadal zapewnia ogólną funkcjonalność

Oczywiście nikt nie zmusza Cię do pisania kodu OOP, a jest wiele funkcji językowych, które są dostępne, ale są niezadowolone, na przykład refleksja.

Oprócz wszystkich wcześniejszych, wyobraź sobie właściwość Tag, która jest typu obiektowego. Umożliwia przechowywanie wybranego obiektu w innym obiekcie do późniejszego wykorzystania w razie potrzeby. Musisz sprowadzić tę właściwość.

Ogólnie rzecz biorąc, nieużywanie czegoś do dzisiaj nie zawsze oznacza coś bezużytecznego ;-)

Najczęstszym zastosowaniem downcastingu w mojej pracy jest to, że jakiś idiota łamie zasadę substytucji Liskowa.

Wyobraź sobie, że w niektórych bibliotekach zewnętrznych jest interfejs.

public interface Foo
{
     void SayHello();
     void SayGoodbye();
 }

I 2 klasy, które to implementują. Bara Qux. Barjest dobrze wychowany.

public class Bar
{
    void SayHello()
    {
        Console.WriteLine(“Bar says hello.”);
    }
    void SayGoodbye()
    {
         Console.WriteLine(“Bar says goodbye”);
    }
}

Ale Quxnie jest dobrze wychowany.

public class Qux
{
    void SayHello()
    {
        Console.WriteLine(“Qux says hello.”);
    }
    void SayGoodbye()
    {
        throw new NotImplementedException();
    }
}

Cóż ... teraz nie mam wyboru. I mają na typ kontroli i (ewentualnie) przygnębiony, aby uniknąć mój program zatrzymał się upaść.

Innym przykładem w świecie rzeczywistym jest WPF VisualTreeHelper. Wykorzystuje downcast do przesyłania DependencyObjectdo Visuali Visual3D. Na przykład VisualTreeHelper.GetParent . Downcast odbywa się w VisualTreeUtils.AsVisualHelper :

private static bool AsVisualHelper(DependencyObject element, out Visual visual, out Visual3D visual3D)
{
    Visual elementAsVisual = element as Visual;

    if (elementAsVisual != null)
    {
        visual = elementAsVisual;
        visual3D = null;
        return true;
    }

    Visual3D elementAsVisual3D = element as Visual3D;

    if (elementAsVisual3D != null)
    {
        visual = null;
        visual3D = elementAsVisual3D;
        return true;
    }            

    visual = null;
    visual3D = null;
    return false;
}