Войти
ФлеймФорумПрограммирование

Интерфейсы в C# 8.0 (3 стр)

Страницы: 1 2 3 4 5 6 7 Следующая »
#30
13:50, 4 сен. 2019

Мизраэль
> Выпустить новую версию интерфейса? Нет?
Мне кажется, они хотят свои же косяки таким образом исправлять. Например, есть, к примеру, интерфейс IEnumerable, прибитый гвоздями к фреймворку и даже языку, но хочется в него новые методы добавить, а вот сделать этого нельзя - потому что пользовательские коллекции все дружно сдохнут, и новый интерфейс сделать нельзя, потому что... ну, блин, как его обозвать? IEnumerable2 ?


#31
14:14, 4 сен. 2019

Нихао
> Мне кажется, они хотят свои же косяки таким образом исправлять. Например, есть,
> к примеру, интерфейс IEnumerable, прибитый гвоздями к фреймворку и даже языку,
> но хочется в него новые методы добавить, а вот сделать этого нельзя - потому
> что пользовательские коллекции все дружно сдохнут, и новый интерфейс сделать
> нельзя, потому что... ну, блин, как его обозвать? IEnumerable2 ?
IDirectDraw2 их ведь не смутило :)

#32
14:40, 4 сен. 2019

Выпустить .NET 5.0 в котором добавить в IEnumerable все что угодно.

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

#33
15:04, 4 сен. 2019

kipar
> Выпустить .NET 5.0 в котором добавить в IEnumerable все что угодно.
Поломать нафиг обратную совместимость? Хотя, они вроде её уже поломали с  nullable reference types :)

#34
15:31, 4 сен. 2019

alexzzzz
> Ты потом в своём коде можешь сделать более эффективную реализацию AddRange под
> конкретно твой случай.
>
>

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

#35
(Правка: 15:46) 15:39, 4 сен. 2019

Мизраэль
> А если использует, то лучше это явно обозначить кастанув к новой версии интерфейса.
а люди не любят кастовать, почему-то. это раз.

во-вторых с кастом тебе придётся писать 2 версии кода, при условии что ты правильно кастуешь.
если новая версия интерфейса реализована, и если новая версия интерфейся НЕ реализована.

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

Мне интересно, а как этот "метод по-умолчанию" работает с внешними объектами.
допустим есть .dll из которой я получаю некий интерфейс.
И как C# будет знать, есть ли у получаемого интерфейса свой метод по-умолчанию, или его нет?!

Скорее всего не знает, и не замарачивается; и тупо будет падать (при попытке вызова нового метода) :)

(хотя если .dll это .net assembly, он точно может её прошерстить на реализуемые методы, и "подставить" метод по-умолчанию... но скорость же!)

#36
15:46, 4 сен. 2019

skalogryz
> то расширять произвольный интерфейс

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

#37
15:56, 4 сен. 2019

gamedevfor
> Тру интерфейсы есть только в COM.
Тру. Только в железе. Хотя чем тебя LPT, например, не устроил, уж не знаю.

#38
16:00, 4 сен. 2019

Нихао
> Хотя, они вроде её уже поломали с nullable reference types :)
  И ещё сто раз до этого и после этого.

slepov
> Мысль понятна, но это начисто ломает весь смысл интерфейса как описателя
> контракта без имплементации.
  А кто вообще сказал, что в C# или где бы то ни было смысл интерфейсов именно такой? Он везде такой, какой удобно иметь авторам и пользователям. И если уж на то пошло, то какая тебе разница где реализован метод, если тебе важен только контракт?

#39
16:03, 4 сен. 2019

Zefick
> А кто вообще сказал, что в C# или где бы то ни было смысл интерфейсов именно
> такой?

Видимо от слова Интерфейс. Впрочем трусы на голове тоже можно носить

#40
(Правка: 16:06) 16:06, 4 сен. 2019

slepov
> добавлять функционал не нарушая контракта можно и экстеншен методами.
специфичную реализацию в экстеншен не добавишь.

slepov
> что такое расширять? ... А добавлять методы в сам интерфейс - это изменение контракта, а не расширение
> его. Меняя контракт ломаешь имплементации, добавляешь новые требования.
Контрактное программирование вроде как "славится" более высокими расходами на проверку выполнения контракта?!
а с методами по-умолчанию получаешь "халявное" расширение. Т.е. вроде бы контракта и не менял, и дополнительный функционал получил xD

#41
16:27, 4 сен. 2019

skalogryz
> Контрактное программирование вроде как "славится" более высокими расходами на проверку выполнения контракта?!
При чём тут вообще контрактное программирование к интерфейсам в ООП?

#42
16:33, 4 сен. 2019

skalogryz
> а с методами по-умолчанию получаешь "халявное" расширение. Т.е. вроде бы
> контракта и не менял, и дополнительный функционал получил xD

Ну я итак понапишу "халявных" методов в отдельных классах и не буду менять интерфейс. Какая разница где халява? Только в моем случае интерфейс останется чистеньким, там только контракт. А так называемые имплементации по умолчанию - я тоже напишу в отдельных классах. Вызвать их думаю руки не отвалятся. И снова интерфейс как контракт остается чистым. То что сейчас - это месиво контрактов и имплементаций. Собсна на это итак есть абстрактные классы. То что они сделали это опять шаг в сторону множественного наследования абстрактных классов. Т.е от чего бежали к тому и пришли. Здавствуй ошарпеный с++.. только зачем это?

#43
(Правка: 16:39) 16:36, 4 сен. 2019

Нихао
> При чём тут вообще контрактное программирование к интерфейсам в ООП?
slepov
> Мысль понятна, но это начисто ломает весь смысл интерфейса как описателя контракта без имплементации
> ...
> А добавлять методы в сам интерфейс - это изменение контракта, а не расширение его.

Интерфейсы в ООП, как один из способов контрактого программирования.
Интерфейс тебе гарантирует, что некий "объект", реализует вот эти N методов.

slepov
> Ну я итак понапишу "халявных" методов в отдельных классах и не буду менять
> интерфейс. Какая разница где халява?

как это "понапишешь в класс"? в классы ты можешь добавить методов, но если ты с объектом работаешь только через интерфейс (и никогда к напрямую к методам класса), то не взлетит - ты же эти методы не "увидишь". Тебе нужно будет новый интерфейс добавлять.

slepov
> Здавствуй ошарпеный с++
лол! прочитал как "оШпаренный с++"

#44
16:38, 4 сен. 2019

skalogryz
> Интерфейсы в ООП, как один из способов контрактого программирования.
> И

И дальше что? В чем так называемые расходы на контракты? Если C#8 их все равно не отменил, а только вкрячил в них еще и имплементации по дефолту.

Страницы: 1 2 3 4 5 6 7 Следующая »
ФлеймФорумПрограммирование