Здравствуйте, Serginio1, Вы писали:

V>>Абстрактный класс содержит данные, а дефолтная реализация может содержать только алгоритмы.
S>Абстрактный класс может содержать данные, а может и не содержать.

Не-абстрактный класс тоже может не содержать данные и что?


S>Но вот раньше не было такого функционала и плодили классы, там где можно было обойтись свойствами и методами интерфейса.

Ес-но.
И в присутствии множественного наследования эта новая функциональность интерфейсов была бы не нужна.


S>Сейчас когда в интерфейсы ввели возможность реализации
S>надобность в таких классах отпала.

Это малость упрощённый взгляд на вещи.
Рассматривай любую фичу языка в первую очередь как инструмент проектирования.

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


S> Например Stream всего два поля
S>

S> private Stream.ReadWriteTask _activeReadWriteTask;
S> private SemaphoreSlim _asyncActiveSemaphore;
S>

S> Да можно сделать их через свойства интерфейса и сделать его интерфейсом

Плохой пример. ))

Вот более хороший насчёт Stream и обсуждаемого:

public virtual ValueTask<int> ReadAsync (Memory<byte> buffer, System.Threading.CancellationToken cancellationToken = default);

public Task<int> ReadAsync (byte[] buffer, int offset, int count) 
    => ReadAsync(new Memory<byte>(buffer, offset, count), cancellationToken).AsTask();

Здравствуйте, Serginio1, Вы писали:

V>>Абстрактный класс содержит данные, а дефолтная реализация может содержать только алгоритмы.
S>Абстрактный класс может содержать данные, а может и не содержать.

Не-абстрактный класс тоже может не содержать данные и что?


S>Но вот раньше не было такого функционала и плодили классы, там где можно было обойтись свойствами и методами интерфейса.

Ес-но.
И в присутствии множественного наследования эта новая функциональность интерфейсов была бы не нужна.


S>Сейчас когда в интерфейсы ввели возможность реализации
S>надобность в таких классах отпала.

Это малость упрощённый взгляд на вещи.
Рассматривай любую фичу языка в первую очередь как инструмент проектирования.

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


S> Например Stream всего два поля
S>

S> private Stream.ReadWriteTask _activeReadWriteTask;
S> private SemaphoreSlim _asyncActiveSemaphore;
S>

S> Да можно сделать их через свойства интерфейса и сделать его интерфейсом

Плохой пример. ))

Вот более хороший насчёт Stream и обсуждаемого:

public virtual ValueTask<int> ReadAsync (Memory<byte> buffer, CancellationToken cancellationToken = default);

public Task<int> ReadAsync (byte[] buffer, int offset, int count) 
    => ReadAsync(new Memory<byte>(buffer, offset, count), cancellationToken).AsTask();