Что такое правильное использование downcasting?

Понижение означает преобразование из базового класса (или интерфейса) в подкласс или листовой класс.

Примером снижения может быть, если вы приведете System.Objectк другому типу.

Даункастинг непопулярен, может быть, пахнет кодом: доктрина объектно-ориентированного подхода предпочитает, например, определять и вызывать виртуальные или абстрактные методы, а не унижать.

• Какие, если таковые имеются, хорошие и правильные варианты использования для даункинг? То есть, при каких обстоятельствах уместно писать код, который преуменьшает значение?
• Если ваш ответ «нет», то почему языком поддерживается пониженная версия?

Вот некоторые правильные способы использования downcasting.

И я с уважением категорически не согласен с другими здесь, которые говорят, что использование downcast - это определенно запах кода, потому что я считаю, что нет другого разумного способа решения соответствующих проблем.

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

Если вы собираетесь сказать, что это запахи кода, вам нужно предоставить более эффективные решения для них (даже если их избежать из-за неудобств). Я не верю, что существуют лучшие решения.

Даункастинг непопулярен, возможно, запах

Я не согласен. Даункинг чрезвычайно популярен ; огромное количество реальных программ содержат один или несколько downcast. И это не может быть запах кода. Это определенно кодовый запах. Вот почему операция даункейтинга должна быть указана в тексте программы . Это так, что вы можете легче заметить запах и уделить внимание проверке кода.

при каких обстоятельствах [s] уместно писать код, который преуменьшает?

В любых обстоятельствах, когда:

• у вас есть 100% правильное знание факта о типе выражения во время выполнения, который является более конкретным, чем тип выражения во время компиляции, и
• вам нужно воспользоваться этим фактом, чтобы использовать возможности объекта, недоступные для типа времени компиляции, и
• это лучше использовать время и усилия, чтобы написать актерский состав, чем реорганизовать программу, чтобы исключить любой из первых двух пунктов.

Если вы можете дешево реорганизовать программу, чтобы компилятор мог определить тип среды выполнения или реорганизовать программу, чтобы вам не требовались возможности более производного типа, тогда сделайте это. Даункасты были добавлены к языку для тех обстоятельств, когда трудно и дорого рефакторинг программы.

почему даункинг поддерживается языком?

C # был изобретен прагматичными программистами, у которых есть работа, для прагматичных программистов, у которых есть работа. Дизайнеры C # не являются пуристами OO. И система типов C # не идеальна; по своей конструкции он недооценивает ограничения, которые могут быть наложены на тип переменной во время выполнения.

Кроме того, downcasting очень безопасен в C #. У нас есть надежная гарантия, что downcast будет проверен во время выполнения, и если его невозможно будет проверить, тогда программа сделает правильные вещи и вылетит. Это замечательно; это означает, что если ваше 100% правильное понимание семантики типов окажется правильным на 99,99%, то ваша программа работает 99,99% времени и в остальное время вылетает, а не ведет себя непредсказуемо и портит пользовательские данные 0,01% времени ,

УПРАЖНЕНИЕ: есть по крайней мере один способ произвести даункаст в C # без использования явного оператора приведения. Можете ли вы вспомнить какие-либо такие сценарии? Поскольку это также потенциальные запахи кода, как вы думаете, какие конструктивные факторы были заложены в разработку функции, которая могла бы привести к падению с понижением при отсутствии явного приведения в коде?

Обработчики событий обычно имеют подпись MethodName(object sender, EventArgs e). В некоторых случаях можно обрабатывать событие, не обращая внимания на то, что это за тип sender, или даже вообще не использовать sender, но в других senderнеобходимо привести к более конкретному типу для обработки события.

Например, у вас может быть два TextBoxs, и вы хотите использовать один делегат для обработки события от каждого из них. Затем вам нужно привести senderк TextBoxтак, чтобы вы могли получить доступ к необходимым свойствам для обработки события:

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

Да, в этом примере вы можете создать свой собственный подкласс, TextBoxкоторый делал это внутренне. Не всегда практично или возможно, хотя.

Вам нужно понизить рейтинг, когда что-то дает вам супертип, и вам нужно обращаться с ним по-разному в зависимости от подтипа.

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

Нет, это не пахнет хорошо. В идеальном мире Donationбыл бы абстрактный метод, getValueи каждый реализующий подтип имел бы соответствующую реализацию.

Но что, если эти классы взяты из библиотеки, которую вы не можете или не хотите менять? Тогда другого варианта нет.

Чтобы добавить к ответу Эрика Липперта, так как я не могу комментировать ...

Вы можете часто избегать снижения рейтинга путем рефакторинга API для использования обобщений. Но дженерики не были добавлены в язык до версии 2.0 . Поэтому, даже если ваш собственный код не нуждается в поддержке версий на древнем языке, вы можете использовать устаревшие классы, которые не параметризованы. Например, некоторый класс может быть определен так, чтобы нести полезную нагрузку типа Object, которую вы вынуждены привести к типу, который, как вы знаете, на самом деле является.

Существует компромисс между статическими и динамически типизированными языками. Статическая типизация дает компилятору много информации, чтобы иметь возможность давать довольно сильные гарантии безопасности (частей) программ. Однако это обходится дорого, потому что вам нужно не только знать, что ваша программа корректна, но вы должны написать соответствующий код, чтобы убедить компилятор, что это так. Другими словами, предъявлять претензии легче, чем доказывать их.

Существуют «небезопасные» конструкции, которые помогут вам сделать недоказанные утверждения для компилятора. Например, безусловные вызовы Nullable.Value, безусловные откаты, dynamicобъекты и т. Д. Они позволяют вам утверждать утверждение («Я утверждаю, что объект a- это String, если я ошибаюсь, выбрасываю InvalidCastException») без необходимости доказывать это. Это может быть полезно в тех случаях, когда доказать это значительно сложнее, чем стоит.

Злоупотребление этим рискованно, именно поэтому явная нисходящая нотация существует и является обязательной; это синтаксическая соль, предназначенная для привлечения внимания к небезопасной операции. Язык мог бы быть реализован с неявным понижением (где выводимый тип однозначен), но это скрыло бы эту небезопасную операцию, что нежелательно.

Даункинг считается плохим по нескольким причинам. В первую очередь я думаю, потому что это анти-ООП.

ООП действительно понравилось бы, если бы вам никогда не приходилось опускать руки, потому что его смысл - в том, что полиморфизм означает, что вам не нужно идти

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

ты просто делаешь

x.DoThing()

и код автоматически делает правильные вещи.

Есть несколько «веских» причин не опускать руки:

• В C ++ это медленно.
• Вы получаете ошибку во время выполнения, если выбираете неправильный тип.

Но альтернатива понижению в некоторых сценариях может быть довольно уродливой.

Классическим примером является обработка сообщений, когда вы не хотите добавлять функцию обработки к объекту, а оставляете ее в обработчике сообщений. Затем у меня есть тонна MessageBaseClassмассива для обработки, но для корректной обработки мне также нужен каждый из них по подтипу.

Вы можете использовать Double Dispatch, чтобы обойти проблему ( https://en.wikipedia.org/wiki/Double_dispatch ) ... Но это также имеет свои проблемы. Или вы можете просто унынуть из-за простого кода, рискуя этими вескими причинами.

Но это было до того, как были изобретены дженерики. Теперь вы можете избежать даункинга, указав тип, где детали указаны позже.

MessageProccesor<T> может варьировать параметры метода и возвращаемые значения указанным типом, но все же предоставлять общие функциональные возможности

Конечно, никто не заставляет вас писать ООП-код, и существует множество языковых функций, которые предоставляются, но не одобряются, например рефлексия.

В дополнение ко всему, что уже было сказано, представьте свойство Tag, имеющее тип object. Он позволяет вам сохранить выбранный вами объект в другом объекте для дальнейшего использования по мере необходимости. Вам нужно понизить это свойство.

В общем, неиспользование чего-либо до сегодняшнего дня не всегда является признаком чего-то бесполезного ;-)

Самое распространенное использование уныния в моей работе связано с тем, что какой-то идиот нарушает принцип замещения Лискова.

Представьте, что в какой-то третьей стороне есть интерфейс.

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

И 2 класса, которые это реализуют. Barи Qux. Barхорошо себя ведет

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

Но Quxплохо себя ведет.

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

Ну ... теперь у меня нет выбора. Я должен напечатать check и (возможно) downcast, чтобы избежать остановки моей программы.

Другой реальный пример - WPF VisualTreeHelper. Он использует downcast для приведения DependencyObjectк Visualи Visual3D. Например, VisualTreeHelper.GetParent . Понижение происходит в 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;
}