Apa gunanya downcasting?

Downcasting berarti casting dari kelas dasar (atau antarmuka) ke kelas subclass atau daun.

Contoh downcast mungkin jika Anda beralih dari System.Objectke jenis lainnya.

Downcasting tidak populer, mungkin bau kode: Doktrin Berorientasi Objek adalah lebih suka, misalnya, mendefinisikan dan memanggil metode virtual atau abstrak daripada downcasting.

• Apa, jika ada, kasus penggunaan yang baik dan tepat untuk downcasting? Artinya, dalam keadaan apa sajakah yang tepat untuk menulis kode yang mengecewakan?
• Jika jawaban Anda adalah "tidak ada", lalu mengapa downcasting didukung oleh bahasa?

Berikut adalah beberapa penggunaan downcasting yang tepat.

Dan saya dengan penuh hormat sangat tidak setuju dengan orang lain di sini yang mengatakan penggunaan downcast jelas merupakan bau kode, karena saya percaya tidak ada cara lain yang masuk akal untuk menyelesaikan masalah yang terkait.

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

Jika Anda akan mengatakan ini bau kode, Anda perlu memberikan solusi yang lebih baik untuk mereka (bahkan jika mereka dihindari karena ketidaknyamanan). Saya tidak percaya ada solusi yang lebih baik.

Downcasting tidak populer, mungkin bau kode

Saya tidak setuju. Downcasting sangat populer ; sejumlah besar program di dunia nyata berisi satu atau lebih downcast. Dan itu mungkin bukan bau kode. Ini jelas merupakan bau kode. Itu sebabnya operasi downcasting diperlukan untuk menjadi nyata dalam teks program . Ini agar Anda bisa lebih mudah memperhatikan aroma dan menghabiskan perhatian review kode di atasnya.

dalam keadaan apa [s] yang tepat untuk menulis kode yang downcasts?

Dalam keadaan apa pun di mana:

• Anda memiliki 100% pengetahuan yang benar tentang fakta tentang tipe runtime dari sebuah ekspresi yang lebih spesifik daripada tipe kompilasi-waktu dari ekspresi, dan
• Anda perlu memanfaatkan fakta itu untuk menggunakan kemampuan objek yang tidak tersedia pada tipe waktu kompilasi, dan
• ini adalah penggunaan waktu dan upaya yang lebih baik untuk menulis para pemeran daripada untuk memperbaiki program untuk menghilangkan salah satu dari dua poin pertama.

Jika Anda bisa dengan murah merevisi sebuah program sehingga tipe runtime dapat dideduksi oleh kompiler, atau untuk merevisi program sehingga Anda tidak memerlukan kemampuan dari tipe yang lebih diturunkan, maka lakukanlah. Orang-orang yang tertekan ditambahkan ke bahasa untuk keadaan-keadaan di mana sulit dan mahal untuk dengan demikian memperbaiki program.

mengapa downcasting didukung oleh bahasa?

C # ditemukan oleh programmer pragmatis yang memiliki pekerjaan untuk dilakukan, untuk programmer pragmatis yang memiliki pekerjaan untuk dilakukan. Desainer C # bukanlah puritan OO. Dan sistem tipe C # tidak sempurna; oleh desain itu meremehkan pembatasan yang dapat ditempatkan pada jenis runtime dari suatu variabel.

Juga, downcasting sangat aman di C #. Kami memiliki jaminan kuat bahwa downcast akan diverifikasi pada saat runtime dan jika tidak dapat diverifikasi maka program melakukan hal yang benar dan crash. Ini luar biasa; itu berarti bahwa jika 100% pemahaman Anda yang benar tentang tipe semantik ternyata 99,99% benar, maka program Anda bekerja 99,99% dari waktu dan crash sisa waktu, bukannya berperilaku tak terduga dan merusak data pengguna 0,01% dari waktu .

LATIHAN: Setidaknya ada satu cara untuk menghasilkan downcast dalam C # tanpa menggunakan operator pemeran eksplisit. Bisakah Anda memikirkan skenario seperti itu? Karena ini juga merupakan bau kode yang potensial, menurut Anda faktor desain apa yang masuk ke dalam desain fitur yang dapat menghasilkan crash yang terputus-putus tanpa ada pemain nyata dalam kode tersebut?

Penangan acara biasanya memiliki tanda tangan MethodName(object sender, EventArgs e). Dalam beberapa kasus mungkin untuk menangani acara tanpa memperhatikan apa jenisnya sender, atau bahkan tanpa menggunakan sendersama sekali, tetapi dalam kasus lain senderharus dilemparkan ke jenis yang lebih spesifik untuk menangani acara tersebut.

Misalnya, Anda mungkin memiliki dua TextBoxdan Anda ingin menggunakan satu delegasi untuk menangani suatu acara dari masing-masing. Kemudian Anda akan perlu untuk membuang senderke TextBoxsehingga Anda bisa mengakses sifat yang diperlukan untuk menangani acara:

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

Ya, dalam contoh ini, Anda dapat membuat subkelas Anda sendiri TextBoxyang melakukan ini secara internal. Namun, tidak selalu praktis atau mungkin.

Anda perlu downcasting ketika sesuatu memberi Anda supertype dan Anda perlu menanganinya secara berbeda tergantung pada subtipe.

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

Tidak, ini baunya tidak enak. Dalam dunia yang sempurna Donationakan memiliki metode abstrak getValuedan setiap subtipe implementasi akan memiliki implementasi yang tepat.

Tetapi bagaimana jika kelas-kelas ini dari perpustakaan Anda tidak bisa atau tidak ingin berubah? Maka tidak ada pilihan lain.

Untuk menambah jawaban Eric Lippert karena saya tidak bisa berkomentar ...

Anda sering dapat menghindari downcasting dengan refactoring API untuk menggunakan obat generik. Tetapi obat generik tidak ditambahkan ke bahasa sampai versi 2.0 . Jadi, bahkan jika kode Anda sendiri tidak perlu mendukung versi bahasa kuno, Anda mungkin menemukan diri Anda menggunakan kelas-kelas lama yang tidak parameter. Sebagai contoh, beberapa kelas mungkin didefinisikan untuk membawa payload tipe Object, yang Anda dipaksa untuk melemparkan ke tipe yang Anda tahu sebenarnya.

Ada pertukaran antara bahasa statis dan diketik secara dinamis. Pengetikan statis memberi kompiler banyak informasi untuk dapat membuat jaminan yang agak kuat tentang keamanan (bagian dari) program. Namun, hal ini berbiaya, karena Anda tidak hanya perlu tahu bahwa program Anda benar, tetapi Anda harus menulis kode yang sesuai untuk meyakinkan kompiler bahwa ini adalah masalahnya. Dengan kata lain, membuat klaim lebih mudah daripada membuktikannya.

Ada konstruksi "tidak aman" yang membantu Anda membuat pernyataan yang tidak terbukti ke kompiler. Misalnya, panggilan tanpa syarat ke Nullable.Value, downcast tanpa syarat, dynamicobjek, dll. Mereka memungkinkan Anda untuk mengajukan klaim ("Saya menyatakan bahwa objek aadalah String, jika saya salah, melempar InvalidCastException") tanpa perlu membuktikannya. Ini dapat berguna dalam kasus-kasus di mana membuktikannya secara signifikan lebih sulit daripada bermanfaat.

Menyalahgunakan ini berisiko, itulah sebabnya mengapa notasi downcast eksplisit ada dan wajib; itu garam sintaksis dimaksudkan untuk menarik perhatian operasi yang tidak aman. Bahasa tersebut dapat diimplementasikan dengan downcasting implisit (di mana jenis yang disimpulkan tidak ambigu), tetapi itu akan menyembunyikan operasi yang tidak aman ini, yang tidak diinginkan.

Downcasting dianggap buruk karena beberapa alasan. Terutama saya pikir karena itu anti-OOP.

OOP akan sangat menyukainya jika Anda tidak pernah harus tertunduk karena '' raison-d'etre '' adalah bahwa polimorfisme berarti Anda tidak perlu pergi

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

kamu lakukan saja

x.DoThing()

dan kode secara otomatis melakukan hal yang benar.

Ada beberapa alasan 'sulit' untuk tidak tertunduk:

• Dalam C ++ lambat.
• Anda mendapatkan kesalahan runtime jika Anda memilih jenis yang salah.

Tetapi alternatif untuk downcasting dalam beberapa skenario bisa sangat jelek.

Contoh klasiknya adalah pemrosesan pesan, di mana Anda tidak ingin menambahkan fungsi pemrosesan ke objek, tetapi simpan di pengolah pesan. Saya kemudian memiliki satu ton MessageBaseClassdalam array untuk diproses, tetapi saya juga membutuhkan masing-masing dengan subtipe untuk pemrosesan yang benar.

Anda dapat menggunakan Double Dispatch untuk menyelesaikan masalah ( https://en.wikipedia.org/wiki/Double_dispatch ) ... Tetapi itu juga memiliki masalah. Atau Anda bisa downcast untuk beberapa kode sederhana dengan risiko alasan-alasan sulit itu.

Tapi ini sebelum Generik ditemukan. Sekarang Anda dapat menghindari downcasting dengan menyediakan jenis yang detailnya ditentukan kemudian.

MessageProccesor<T> dapat memvariasikan parameter metode dan mengembalikan nilai menurut tipe yang ditentukan tetapi tetap menyediakan fungsionalitas umum

Tentu saja tidak ada yang memaksa Anda untuk menulis kode OOP dan ada banyak fitur bahasa yang disediakan tetapi disukai, seperti refleksi.

Selain semua yang dikatakan sebelumnya, bayangkan properti Tag yang bertipe objek. Ini memberikan cara bagi Anda untuk menyimpan objek pilihan Anda di objek lain untuk digunakan nanti yang Anda butuhkan. Anda perlu downcast properti ini.

Secara umum, tidak menggunakan sesuatu sampai hari ini tidak selalu merupakan indikasi sesuatu yang tidak berguna ;-)

Penggunaan downcasting yang paling umum dalam pekerjaan saya adalah karena beberapa orang idiot yang melanggar prinsip Pergantian Liskov.

Bayangkan ada antarmuka di beberapa lib pihak ketiga.

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

Dan 2 kelas yang mengimplementasikannya. Bardan Qux. Barberperilaku baik.

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

Tetapi Quxtidak berperilaku baik.

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

Baiklah ... sekarang saya tidak punya pilihan. Saya harus mengetik cek dan (mungkin) downcast untuk menghindari program saya terhenti.

Contoh dunia nyata lainnya adalah WPF VisualTreeHelper. Ini menggunakan downcast untuk melemparkan DependencyObjectke Visualdan Visual3D. Misalnya, VisualTreeHelper.GetParent . Downcast terjadi di 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;
}