Downcasting'in doğru kullanımı nedir?

Alt yayın, bir temel sınıftan (veya arayüzden) bir alt sınıfa veya yaprak sınıfına döküm yapmak anlamına gelir.

Bir System.Objectbaşka yayın türünden başka bir gruba yayın yaparsanız aşağı akış örneği olabilir .

Downcasting popüler değil, belki de bir kod kokusu: Nesne Yönelimli doktrin, örneğin downcasting yerine sanal veya soyut yöntemleri tanımlama ve çağırmayı tercih etmektir.

• Varsa, downcasting için iyi ve uygun kullanım durumları nelerdir? Diğer bir deyişle, hangi durumlarda, aşağıya yüklenen kod yazmak uygun olur?
• Cevabınız "yok" ise, neden dil üstü yayıncılık neden destekleniyor?

İşte sağanaklığın bazı doğru kullanımları.

Ve ben burada saygısız bir şekilde, aşağıya doğru kullanımın kesinlikle bir kod kokusu olduğunu söyleyen diğerlerine şiddetle karşı çıkıyorum çünkü ilgili sorunları çözmenin başka makul bir yolu olmadığına inanıyorum.

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

Bunların kod kokuları olduğunu söyleyecekseniz, onlar için daha iyi çözümler sunmanız gerekir (rahatsızlıktan kaçınılsalar bile). Daha iyi çözümlerin var olduğuna inanmıyorum.

Downcasting popüler değil, belki bir kod kokusu

Katılmıyorum. Downcasting son derece popüler ; Çok sayıda gerçek dünya programı, bir veya daha fazla downcast içerir. Ve belki de bir kod kokusu değil. Öyle kesinlikle bir kod koku. Bu nedenle, indirme işleminin programın metninde tezahür etmesi zorunludur . Kokuyu daha kolay fark edebilmeniz ve kod incelemesine dikkat etmek için harcayacağınız şekilde.

Hangi durumda [ları] hangi indirmeleri kod yazmak uygun olur?

Herhangi bir durumda:

• ifadenin derleme zamanı türünden daha belirgin olan bir ifadenin çalışma zamanı türü ile ilgili bir gerçek hakkında % 100 doğru bilgiye sahipseniz ve
• Derleme zamanı türünde bulunmayan nesnenin yeteneğini kullanmak için bu gerçeğin avantajlarından yararlanmanız gerekir.
• Oyuncu kadrosunu yazmak için zaman ve çabanın kullanılması, ilk iki noktanın herhangi birini ortadan kaldırmak için programı yeniden düzenlemekten daha iyidir.

Bir programı ucuza yeniden düzenleyebilir, böylece çalışma zamanı türü derleyici tarafından çıkarılabilir ya da daha fazla türetilmiş türün kapasitesine gerek duymamanız için programı yeniden düzenleyebilirseniz, bunu yapın. Programı yeniden düzenlemenin zor ve pahalı olduğu durumlar için dile aşağıya doğru yayınlar eklendi .

Neden downcasting dili tarafından destekleniyor?

C #, yapılacak işleri var pragmatik programcılar tarafından icat edilmiştir için yapılacak işler var pragmatik programcılar. C # tasarımcıları OO purists değildir. Ve C # tipi sistem mükemmel değildir; tasarım gereği, bir değişkenin çalışma zamanına yerleştirilebilecek kısıtlamaları hafife alır.

Ayrıca, downcasting C # ile çok güvenlidir. Downcast'in çalışma zamanında doğrulanacağına dair kesin bir garantimiz var ve eğer doğrulanamazsa program doğru olanı yapıyor ve çöküyor. Bu harika; % 100 doğru anlam anlayışı türünün% 99,99 doğru olduğu ortaya çıkarsa, programınız zamanın% 99,99'unu çalıştırır ve zamanın% 99,99'unu tahmin edilemez davranmak ve kullanıcı verilerini% 0,01 oranında bozmak yerine çöker. .

EGZERSİZ: Açık bir döküm operatörü kullanmadan C # ' da bir downcast üretmenin en az bir yolu vardır . Böyle bir senaryo düşünebiliyor musunuz? Bunlar aynı zamanda potansiyel kod kokuları olduğu için, kodda açık bir döküm yapmadan bir downcast çökmesine neden olabilecek bir özelliğin tasarımında hangi tasarım faktörlerinin kullanıldığını düşünüyorsunuz?

Olay işleyicileri genellikle imzaya sahiptir MethodName(object sender, EventArgs e). Bazı durumlarda olayı ne tür senderolduğuna bakılmaksızın veya hatta hiç kullanmadan kullanmak mümkündür sender, ancak bazılarında senderolayı işlemek için daha spesifik bir türe atılmalıdır.

Örneğin, iki TextBoxkişiniz olabilir ve her birinden bir etkinliği işlemek için tek bir temsilci kullanmak isteyebilirsiniz. Sonra olayı işlemek için gerekli özelliklere erişebilmeniz senderiçin bir döküm yapmanız gerekir TextBox:

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

Evet, bu örnekte, bunu TextBoxdahili olarak yapan kendi alt sınıfınızı oluşturabilirsiniz . Her zaman pratik ya da mümkün olmasa da.

Bir şey size bir süper tip verdiğinde ve çok alt tipe bağlı olarak farklı şekilde ele almanız gerektiğinde downcasting gerekir.

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

Hayır, bu iyi kokmuyor. Mükemmel bir dünyada Donationsoyut bir yöntem olacaktı getValueve her uygulama alt tipi uygun bir uygulamaya sahip olacaktı.

Peki ya bu sınıflar kütüphaneden geliyorsa, değiştiremezsiniz veya değiştirmek istemezseniz? O zaman başka bir seçenek yok.

Yorum yazamadığımdan beri Eric Lippert'in cevabını eklemek için ...

Generikleri kullanmak için bir API'yi yeniden gözden geçirerek sık sık aşağıya düşmeyi önleyebilirsiniz. Ancak jenerikler, 2.0 sürümüne kadar dile eklenmedi . Bu nedenle, kendi kodunuzun eski dil sürümlerini desteklemesi gerekmese bile, kendinizi parametrelendirilmemiş eski sınıfları kullanarak bulabilirsiniz. Örneğin, bazı sınıflar, Objectgerçekte bildiğiniz türe basmak zorunda kaldığınız bir tür yük taşıyacak şekilde tanımlanabilir .

Statik ve dinamik olarak yazılmış diller arasında bir denge vardır. Statik yazım, derleyiciye, programların (bazı bölümlerinin) güvenliği hakkında oldukça güçlü garanti verebilecek birçok bilgi verir. Ancak bunun bir bedeli var çünkü programınızın doğru olduğunu bilmeniz gerekmez, aynı zamanda derleyiciyi bu durumda olduğuna ikna etmek için uygun kodu yazmanız gerekir. Başka bir deyişle, iddiada bulunmak, kanıtlamaktan daha kolaydır.

Derleyiciye kanıtlanamayan iddialarda bulunmanıza yardımcı olacak "güvensiz" yapılar vardır . Örneğin, şartsız çağrılar Nullable.Value, koşulsuz downcasts, dynamicvb nesneler, Onlar bir iddiada izin ( "Ben bu nesne iddia abir olduğunu Stringyanılıyorsam, atmak bir InvalidCastException") olmadan bunu kanıtlamak gerek. Bu, kanıtlamanın değerliden daha zor olduğu durumlarda faydalı olabilir.

Bunu kötüye kullanmak risklidir, bu nedenle açık downcast gösterimi var ve zorunludur; öyle sözdizimsel tuz güvenli olmayan bir operasyonda dikkat çekmek içindir. Dil , örtük aşağı yayınlama ile uygulanmış olabilir (çıkarılan türün açık olmadığı durumlarda), ancak bu güvenli olmayan işlemi gizler, ki bu arzu edilmez.

Downcasting birkaç nedenden dolayı kötü olarak kabul edilir. Öncelikle düşünüyorum çünkü bu anti-OOP.

OOP, '' raison-d'etre '' olarak asla hayal kırıklığına uğratmak zorunda kalmazsanız, gerçekten hoşuna gider, polimorfizmin gitmek zorunda olmadığınız anlamına gelir.

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

sadece yap

x.DoThing()

ve kod otomatik olarak doğru olanı yapar.

Havaya uçmamak için bazı 'zor' sebepler var:

• C ++ 'da yavaştır.
• Yanlış tipi seçerseniz çalışma zamanı hatası alırsınız.

Ancak, bazı senaryolarda yer alan uydudan yayınlamaya alternatif oldukça çirkin olabilir.

Klasik örnek, işleme işlevini nesneye eklemek istemediğiniz ancak mesaj işlemcisinde saklamak istemediğiniz mesaj işlemesidir. Daha sonra MessageBaseClassişlemek için bir dizi ton var , ancak aynı zamanda doğru işleme için alt tip her birine ihtiyacım var.

Problemi çözmek için Double Dispatch'i kullanabilirsiniz ( https://en.wikipedia.org/wiki/Double_dispatch ) ... Ama bunun da sorunları var. Ya da bu zor nedenlerle risk altında basit bir kod için sadece downcast yapabilirsiniz.

Fakat bu Jeneriklerin icat edilmesinden önceydi. Artık ayrıntıların daha sonra belirtildiği bir tür sağlayarak aşağıya doğru yayılmasını önleyebilirsiniz.

MessageProccesor<T> yöntem parametrelerini değiştirebilir ve değerleri belirtilen türe göre değiştirebilir ancak yine de genel işlevsellik sağlayabilir

Elbette hiç kimse sizi OOP kodu yazmaya zorlamıyor ve yansıma gibi sağlanan ancak kaşlarını çattığınız birçok dil özelliği var.

Daha önce söylenenlere ek olarak, type nesnesine ait bir Tag özelliğini hayal edin. İstediğiniz nesneyi daha sonra kullanmak için başka bir nesnede saklamanız için bir yol sağlar. Bu özellik için aşağıya ihtiyacınız var.

Genel olarak, bugüne kadar bir şey kullanmamak her zaman işe yaramaz bir şeyin göstergesi değildir ;-)

İşimde aşağıya akmanın en yaygın kullanımı, Liskov'un Yerine Getirilmesi ilkesini bozan bir salak yüzünden.

Bazı üçüncü taraf kütüphanelerinde bir arayüz olduğunu hayal edin.

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

Ve onu uygulayan 2 sınıf. Barve Qux. Bariyi davrandı.

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

Ama Quxiyi davranılmamış.

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

Şey ... şimdi başka bir seçeneğim yok. Ben var benim program bir çökmesini durma noktasına geldi zorunda kalmamak için onay ve (muhtemelen) mahzun yazın.

Başka bir gerçek dünya örneği WPF'ler VisualTreeHelper. Bu döküm için mahzun kullanır DependencyObjectetmek Visualve Visual3D. Örneğin, VisualTreeHelper.GetParent . Downcast VisualTreeUtils.AsVisualHelper içinde gerçekleşir :

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