Каковы преимущества использования базового класса для определения производного класса? [Дубликат]

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

Это отличается от переопределения элемента базового класса; для этого элемент базового класса должен быть помечен как абстрактный или виртуальный. Так что не каждый член базового класса может быть переопределен. Предположим, вы подклассифицируете класс из чужой сборки, и у вас нет доступа или не хотите возвращаться и модифицировать этот код, чтобы сделать участников виртуальными. Без нового ключевого слова вы бы застряли.

Вы можете утверждать, лучше ли иметь ключевое слово и быть явным (мое мнение) или просто сделать это неявно.

В C # члены запечатываются по умолчанию, что означает, что вы не можете их переопределить (если они не помечены ключевыми словами virtual или abstract) и по соображениям производительности . Новый модификатор используется, чтобы явно скрыть унаследованный элемент.

Если переопределение было по умолчанию без указания ключевого слова override, вы можете случайно переопределить какой-либо метод своей базы только из-за равенства имен.

. Стратегия компилятора .Net - это выдавать предупреждения, если что-то может пойти неправильно, чтобы быть в безопасности, поэтому в этом случае, если переопределение было по умолчанию, должно быть предупреждение для каждого метода overriden - что-то вроде «warning: проверьте, действительно ли вы хотите переопределить».

Стоит отметить, что эффект только new в этом контексте заключается в подавлении предупреждения. В семантике нет изменений.

Итак, один ответ: нам нужно new сообщить компилятору, что скрытие намеренное и избавиться от предупреждения.

Следующий вопрос: если вы не будете / не можете переопределить метод, зачем вы вводите другой метод с тем же именем? Потому что скрытие - это, по сути, конфликт имен. И вы, конечно, избегаете этого в большинстве случаев.

Единственная веская причина, по которой я могу думать о намеренном укрытии, - это когда на вас навязывается имя интерфейса.

Если методу в производном классе предшествует новое ключевое слово, этот метод определяется как независимый от метода в базовом классе

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

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

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

Обновлено ... Эрик дал мне представление о том, как улучшить этот пример.

public interface IAction1
{
    int DoWork();
}
public interface IAction2
{
    string DoWork();
}

public class MyBase : IAction1
{
    public int DoWork() { return 0; }
}
public class MyClass : MyBase, IAction2
{
    public new string DoWork() { return "Hi"; }
}

class Program
{
    static void Main(string[] args)
    {
        var myClass = new MyClass();
        var ret0 = myClass.DoWork(); //Hi
        var ret1 = ((IAction1)myClass).DoWork(); //0
        var ret2 = ((IAction2)myClass).DoWork(); //Hi
        var ret3 = ((MyBase)myClass).DoWork(); //0
        var ret4 = ((MyClass)myClass).DoWork(); //Hi
    }
}

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

Одно раздражение с помощью этого подхода - возможно, кто-то может мне помочь, - это то, что я не знаю, как и тень, и переопределить определенное свойство внутри тот же класс. Предоставляет ли какой-либо из языков CLR (я использую vb 2005)? Было бы полезно, если бы объект базового класса и его свойства могли быть абстрактными, но для этого требовалось бы, чтобы промежуточный класс переопределял свойства Value1 до Value40 до того, как класс потомков мог их затенять.