Почему экземпляр производного класса приводят к базовому абстрактному типу?

Question

[Евгений Иванов]

Говорят, что экземпляр производного класса, наследующийся от абстрактного (класса, интерфейса), принято приводить к базовому типу. Почти всегда.
Часто это объясняют тем, что так мы показываем суть нашего объекта.
Пример

Файл Interface1.cs

namespace Interfaces
{
interface Interface1
{
void Method1();
}
}

Файл Interface2.cs

namespace Interfaces
{
interface Interface2
{
void Method2();
}
}

Файл Program.cs

namespace Interfaces
{

class Program
{

class DerivedClass : Interface1, Interface2
{
public void Method1(){Console.WriteLine("Реализация Method1 из Interface1");}
public void Method2(){Console.WriteLine("Реализация Method2 из Interface2");}
}

static void Main()
{
Interface1 instance1 = new  DerivedClass();
Interface2 instance2 = new  DerivedClass();
//DerivedClass instance = new  DerivedClass();

instance1.Method1();
//instance1.Method2(); нельзя

instance2.Method2();
//instance1.Method1(); нельзя

Console.ReadKey(); 
}
}
}

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

Если не приводить к базовому типу то: нам понадобится 1 экземпляр класса. Мы сможем вызывать 2 метода на 1 экземпляре класса. Не нужна "лишняя" операция приведения (апкаст).

Неужели реализация не показывает сути объекта? (Ведь это тоже объект.)
И поэтому мы должны делать апкаст, писать больше кода и вводить для себя ограничения?

Почему экземпляр производного класса приводят к базовому абстрактному типу?

Answer 1

[Василий Банников]

Говорят, что экземпляр производного класса, наследующийся от абстрактного (класса, интерфейса), принято приводить к базовому типу. Почти всегда.

Ни разу о таком не слышал. Мне кажется, это какой-то бред сумасшедшего, который ни разу не написал ни одной строчки кода.

На C# очень многие используют стиль VIP (var if possible), в таком стиле ваш код будет выглядеть так:

var instance = new  DerivedClass();
instance.Method1(); // Красиво, компактно, никаких проблем.
instance.Method2();

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

Нет. Можно написать так:

DerivedClass instance= new DerivedClass(); // только 1 экземпляр
Interface1 instance1 = instance; // Но всё равно очень громоздко.
Interface2 instance2 = instance;

Не нужна "лишняя" операция приведения (апкаст).

Апкаст - это бесплатная операция.

Единтвенный лучай, когда нужно приводить класс к интерфейсу - это явная реализация интерфейса (без апкаста тупо не получится вызвать его методы)
PS: простой код лучше сложного.

Comments

[Евгений Иванов]

Ни разу о таком не слышал. Мне кажется, это какой-то бред сумасшедшего, который ни разу не написал ни одной строчки кода.

Aлексaндр Шeвчук — сертифицирoванный рaзработчик и тренер Microsoft, эксперт в области построения архитектуры информационных систем, бизнес-анализа и управления IT-проектами, автор многих образовательных программ для .NET разработчиков.

Вот вырезка из его видео.
https://cloud.mail.ru/public/49g2/aCrDndr78

[Alew]

Знаете поговорку "кто не умеет работать, тот идет руководить..." ?
по сути вопроса, нет никакого смысла приводить объект к базовому типу, если вы вначале его создали, и после этого вызываете его методы. пример в видео высосан из пальца, в реальных проектах так никто не делает.

[Griboks]

Евгений Иванов,

мы создаем абстрактный и конкретный классы
Но было бы неправильно использовать конкретный класс с точки зрения архитектуры
Зачем же мы тогда создавали абстрактный класс
Потому что так красивее выглядит

Не, ну если все для вас - это вот этот тренер успешно успешного кода, то у него и спрашивайте.

[Василий Банников]

Евгений Иванов, видео смотреть лень, но предположу, что он имел в виду, что-то типа
"Сущности должны зависеть от абстракций, а не от конкретики"
Или
"Функция должна принимать максимально абстрактный параметр, а возвращать максимально конкретный"

[Василий Банников]

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

Answer 2

[Griboks]

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

Простой пример

IEnumerable<T> For(this IEnumerable<T> query, Action<T> action) {
foreach(var item in query) action(item) ;
return query;}

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

Answer 3

[#]

приведение к базовому типу имеет только один рациональный смысл - это дать возможность передавать различных потомков точка