Абстрактрый класс vs Интерфейс. Немного "тиков" и ассемблера

@IcyWind · Регистрация: 19.09.2011

Author24 — интернет-сервис помощи студентам

Правильно ли я понимаю, что абстрактный класс более предпочтителен интерфейсу в вопросах производительности?

C#

public interface Iinter
{
    void SomeMethod();
}
 
public abstract class A : Iinter
{
    public abstract void SomeMethod();
}
 
public class B : A
{
    public override void  SomeMethod()
{
    int i = 10;
    double z = Math.Sqrt((double)i);
}

сам запуск

C#

var time = new Stopwatch();
            var time1 = new Stopwatch();
            var time0 = new Stopwatch();
 
            A temp110 = new B();
            A temp11 = new B();
            Iinter temp10 = new B();
            //для того, чтобы разогреться
            time0.Start();
            
            temp110.SomeMethod();
            time0.Stop();
 
 
            
 
            time.Start();
            temp10.SomeMethod();
            time.Stop();
 
            time1.Start();
            temp11.SomeMethod();
            time1.Stop();

первый прогон для разогрева)
итого (по итогам 7-10 запусков):
Интерфейс: 20-50 Ticks
Абстрактный класс: 0-10 Ticks
Более того, не поленился и полез в дизасемблер:
Интерфейс:

Assembler

1 2	0000020a mov ecx,dword ptr [ebp-44h] 0000020d call dword ptr ds:[0335005Ch]

Абстрактный класс:

Assembler

00000229  mov         ecx,dword ptr [ebp-40h] 
0000022c  mov         eax,dword ptr [ecx] 
0000022e  mov         eax,dword ptr [eax+28h] 
00000231  call        dword ptr [eax+10h]

@kolorotur · 20.10.2013, 02:23

Скажем так, интерфейс и абстрактный класс — это понятия архитектурные, а не процедурные, потому при выборе что из них использовать вопрос о производительности не должен стоять. Это раз.
Два. Нативный код, генерируемый рантаймом для вызова виртуального метода через ссылку на интерфейс или на родительский класс — это деталь реализации, которая не оговаривается спецификацией языка, а значит не является величиной постоянной. Одна версия рантайма под одной системой на одном процессоре сгегерирует один код, другая версия на другой системе с другим процессором сгенерирует совсем другой.
Вы, как разработчик на языке C#, повлиять на количество АСМ-инструкций не в силах по объективным причинам, потому не запаривайтесь по этому поводу.

Интересно как работает — это круто. Главное, чтобы этот интерес не являлся решающим фактором при выборе интерфейс вс. абстрактный класс.

Как-то так.

@IcyWind · 20.10.2013, 02:40 **[ТС]**

Сообщение от kolorotur

при выборе что из них использовать вопрос о производительности не должен стоять

пока для себя решил так:
1.) если набор методов для разных по смыслу классов, то 100% интерфейс (тем более, что это не запрещает наследовать от другого класса)
2.) если нужны какие-то стандартные методы или стандартная реализация, то абстрактный класс
а в остальных случаях...понятно, что для шарпа очень "непривычно" видеть чисто виртуальный абстрактный класс. Ведь, по сути, это и есть интерфейс...но почему бы, когда вопрос производительности стоит не на последнем месте, а набор свойств/методов разрабатывается только для обеспечения полиморфизма не сделать упор именно на производительноть? И ещё: каких правил "интерфейс или абстрактный класс" придерживаетесь лично Вы?
P.s. во всём остальном солидарен

и всё это изучаю исключительно из любопытства

@kolorotur · 20.10.2013, 02:56

Правил придерживаюсь простецких: что сказал начальник, то и реализую

Шутка. Отчасти.

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

Лирическое отступление: суть объектно-ориентированного программирования — моделирование привычной нам реальности в компьютерной системе. Объект — это некая сущность, состоящая из свойств, ее описывающих, и действий, с ней производимых. Если об этом не забывать, то выбирать будет просто: там, где нужно тупо определить поведение без привязки к конкретной сущности (типа "летать") — это интерфейс, т.к. летать могут птицы, самолеты, ракеты, стрелы и камни — абсолютно разные сущности.
Ну а там, где есть сущность, но часть ее нужно "допилить" — это уже абстрактный класс, например "летательный аппарат".
Что, конечно, не мешает абстрактному классу реализовать интерфейс

@IcyWind · 20.10.2013, 03:00 **[ТС]**

Сообщение от kolorotur

Что, конечно, не мешает абстрактному классу реализовать интерфейс

Именно! Всё чаще это встречаю. А при работе с List<T> предпочитаю List<AbstractClass>, чем List<Interface>

@kolorotur · 20.10.2013, 12:10

Сообщение от IcyWind

Всё чаще это встречаю.

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

Сообщение от IcyWind

А при работе с List<T> предпочитаю List<AbstractClass>, чем List<Interface>

Опять же, зависит от архитектуры

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

@kolorotur 17688 / 12873 / 3366 Регистрация: 17.09.2011 Сообщений: 21,138
	20.10.2013, 02:23	2
	Скажем так, интерфейс и абстрактный класс — это понятия архитектурные, а не процедурные, потому при выборе что из них использовать вопрос о производительности не должен стоять. Это раз. Два. Нативный код, генерируемый рантаймом для вызова виртуального метода через ссылку на интерфейс или на родительский класс — это деталь реализации, которая не оговаривается спецификацией языка, а значит не является величиной постоянной. Одна версия рантайма под одной системой на одном процессоре сгегерирует один код, другая версия на другой системе с другим процессором сгенерирует совсем другой. Вы, как разработчик на языке C#, повлиять на количество АСМ-инструкций не в силах по объективным причинам, потому не запаривайтесь по этому поводу. Интересно как работает — это круто. Главное, чтобы этот интерес не являлся решающим фактором при выборе интерфейс вс. абстрактный класс. Как-то так. 1

@IcyWind 9 / 9 / 9 Регистрация: 19.09.2011 Сообщений: 272
	20.10.2013, 02:40 [ТС]	3
	Сообщение от kolorotur при выборе что из них использовать вопрос о производительности не должен стоять пока для себя решил так: 1.) если набор методов для разных по смыслу классов, то 100% интерфейс (тем более, что это не запрещает наследовать от другого класса) 2.) если нужны какие-то стандартные методы или стандартная реализация, то абстрактный класс а в остальных случаях...понятно, что для шарпа очень "непривычно" видеть чисто виртуальный абстрактный класс. Ведь, по сути, это и есть интерфейс...но почему бы, когда вопрос производительности стоит не на последнем месте, а набор свойств/методов разрабатывается только для обеспечения полиморфизма не сделать упор именно на производительноть? И ещё: каких правил "интерфейс или абстрактный класс" придерживаетесь лично Вы? P.s. во всём остальном солидарен и всё это изучаю исключительно из любопытства 0

@kolorotur 17688 / 12873 / 3366 Регистрация: 17.09.2011 Сообщений: 21,138
	20.10.2013, 02:56	4
	Правил придерживаюсь простецких: что сказал начальник, то и реализую Шутка. Отчасти. Принцип выбора интерфейса или абстрактного класса достаточно прост: абстрактный класс описывает сущность, часть которой не может иметь реализации по умолчанию, а интерфейс описывает поведение. Лирическое отступление: суть объектно-ориентированного программирования — моделирование привычной нам реальности в компьютерной системе. Объект — это некая сущность, состоящая из свойств, ее описывающих, и действий, с ней производимых. Если об этом не забывать, то выбирать будет просто: там, где нужно тупо определить поведение без привязки к конкретной сущности (типа "летать") — это интерфейс, т.к. летать могут птицы, самолеты, ракеты, стрелы и камни — абсолютно разные сущности. Ну а там, где есть сущность, но часть ее нужно "допилить" — это уже абстрактный класс, например "летательный аппарат". Что, конечно, не мешает абстрактному классу реализовать интерфейс 1

@IcyWind 9 / 9 / 9 Регистрация: 19.09.2011 Сообщений: 272
	20.10.2013, 03:00 [ТС]	5
	Сообщение от kolorotur Что, конечно, не мешает абстрактному классу реализовать интерфейс Именно! Всё чаще это встречаю. А при работе с List<T> предпочитаю List<AbstractClass>, чем List<Interface> 0

@kolorotur 17688 / 12873 / 3366 Регистрация: 17.09.2011 Сообщений: 21,138
	20.10.2013, 12:10	6
	Сообщение от IcyWind Всё чаще это встречаю. Тут, конечно, важно понимать, что наличие или отсутсвие интерфейса зависит исключительно от архитектуры приложения. Никто не запрещает создавать отдельный интерфейс на каждый чих, но если в программе нет сценария использования этих интерфейсов, то зачем они нужны? Бритва Оккама в действии. Сообщение от IcyWind А при работе с List<T> предпочитаю List<AbstractClass>, чем List<Interface> Опять же, зависит от архитектуры Но по умолчанию, конечно же, используется класс. То есть для использования интерфейса должен иметься повод. 0