Rust vs C++ , очередная шляпа

[D_KEY]

Цитата Wound @ 26.08.19, 14:31

Я же выше написал:

Цитата Wound @ 26.08.19, 13:48

Для интерфейсов есть явная имплементация интерфейса.

Ага, я просто не понял. Спасибо за разъяснения

[Wound]

Но если ты объявишь методы у класса как public и уберешь явную имплементацию интерфейса - то все будет компилироваться. Но я не совсем понимаю - как должно работать в таком случае. В любом языке будет компилироваться.
Это как в С++ удалить чисто-виртуальную функцию в базовом классе.

[D_KEY]

Цитата Wound @ 26.08.19, 14:37

Это как в С++ удалить чисто-виртуальную функцию в базовом классе.

Если в производных классах писали override, то компилятор будет ругаться. Но тут я особой разницы с "явной имплементацией интерфейса" не вижу.

[Wound]

Цитата D_KEY @ 26.08.19, 14:48

Если в производных классах писали override, то компилятор будет ругаться. Но тут я особой разницы с "явной имплементацией интерфейса" не вижу.

Да. Только фишка в том, что в С++ нет интерфейсов, там есть только классы. И абстрактный базовый класс - это частный случай обычного класса. Поэтому ты в любом производном классе можешь написать override.
А в C# там тоже есть абстрактные классы, и это не то же самое что интерфейс, и если класс наследуется от класса, то override - ты тоже можешь писать, никто не запрещает.
А вот в случае с интерфейсом - немного другая фишка. Если ты наследуешься напрямую от интерфейса, то ты не можешь у метода, который имплементишь написать override. Потому что к интерфейсам это не применимо. Ибо интерфейс в C# в принципе не может содержать реализацию, вообще никакую.
Я так полагаю, друг applegame, привык в С++ стайл писать нечто вроде:

     interface MyInterface
    {
        string GetMyString();
        void SetMyString(string value);
    }
 
    public class MyClass : MyInterface
    {
        public string GetMyString()
        {
            return "MyString";
        }
 
        public void SetMyString(string value)
        {
        }
    }

В таком случае, если ты у интерфейса закоментируешь какой то метод. То компилятор будет просто думать, что у класса есть свой метод, не ну а что, это ведь не запрещено. Главное что интерфейс он то реализует.
А вообще эта фича по факту нужна для разруливания множественного наследования интерфейсов.
Что то типа:

    interface IAnimal
    {
        void Run();
    }
 
    interface IBot
    {
        void Run();
    }
 
    public class MyClass : IAnimal, IBot
    {
        void IAnimal.Run()
        {
            /*implementation for Animal*/
        }
 
        void IBot.Run()
        {
            /*implementation for Bot*/
        }
    }
 
    //! А вот тут уже класс реализует в одном методе два интерфейса
    public class MyClass2 : IAnimal, IBot
    {
        public void Run()
        {
            /*implementation for IAnimal and IBot*/
        }
    }

Сообщение отредактировано: Wound - 26.08.19, 15:03

[D_KEY]

Цитата Wound @ 26.08.19, 15:00

Я так полагаю, друг applegame, привык в С++ стайл писать

Но я так понял, там еще D был. И в нем есть интерфейсы.

Добавлено 26.08.19, 15:30
А, но в D можно писать override и для метода из интерфейса.

[Wound]

Цитата D_KEY @ 26.08.19, 15:28

А, но в D можно писать override и для метода из интерфейса.

А в интерфейсе можно реализовать метод? Если нельзя, то какой смысл в слове override? А если можно, то какой смысл в слове interface?

[D_KEY]

Цитата Wound @ 26.08.19, 15:33

А в интерфейсе можно реализовать метод?

Можно, но только через final.
Есть даже такой паттерн NVI называется, в C++ часто встречается, в D пропагандируется, как я понял.

Цитата

Если нельзя, то какой смысл в слове override?

Просто для единообразия. В C++ для чисто виртуальной функции так же можно писать override, тебя же это не смущает.

Цитата

А если можно, то какой смысл в слове interface?

Ну в Java тоже можно реализацию писать(поля нельзя иметь), но все ок.

Сообщение отредактировано: D_KEY - 26.08.19, 15:37

[Wound]

Цитата D_KEY @ 26.08.19, 15:36

Просто для единообразия. В C++ для чисто виртуальной функции так же можно писать override, тебя же это не смущает.

Так в С++ нет интерфейсов, с чего бы меня должно это смущать? А чисто виртуальная функция это частный случай виртуальной.

Цитата D_KEY @ 26.08.19, 15:36

Ну в Java можно реализацию писать(поля нельзя иметь), но все ок.

Ну тогда это уже ближе к абстрактным классам, нежели к интерфейсам, ИМХО.

Цитата D_KEY @ 26.08.19, 15:36

Есть даже такой паттерн NVI называется, в C++ часто встречается, в D пропагандируется, как я понял.

Что за паттерн такой? В С++ может и встречал, но аббревиатура точно не знакомая.

[D_KEY]

Цитата Wound @ 26.08.19, 15:39

А чисто виртуальная функция это частный случай виртуальной.

Но она не имеет реализацию. Так какой смысл в слове override?

Цитата

Ну тогда это уже ближе к абстрактным классам, нежели к интерфейсам, ИМХО.

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

Цитата

Цитата D_KEY @ 26.08.19, 15:36

Есть даже такой паттерн NVI называется, в C++ часто встречается, в D пропагандируется, как я понял.

Что за паттерн такой? В С++ может и встречал, но аббревиатура точно не знакомая.

Non-virtual interface pattern
Если кратко, то ты разделяешь интерфейс для клиента(не виртуальный) и для наследника/реализатора(виртуальный). Клиент работает с одними наборами методов, которые реализуются посредством другого набора методов, которые предоставляет наследник или тот, кто реализует интерфейс. Хорошо ложится на такие паттерны, как шаблонный метод.

Сообщение отредактировано: D_KEY - 26.08.19, 15:45

[Wound]

Цитата D_KEY @ 26.08.19, 15:45

Но она не имеет реализацию. Так какой смысл в слове override?

Вся фишка в том, что эта функция часть класса. А в классах функции могут иметь реализацию. Сегодня она не имеет реализацию, а завтра будет иметь реализацию по умолчанию. А с интерфейсами в C# немного другая история, там даже если ты очень сильно захочешь, реализацию для метода написать ты не сможешь, только реализация в наследуемом классе.
Но вообще, по большому счету, это придирки, да. Но если уж начинать придираться к тому, что в шарпах нельзя писать override для методов класса реализующих интерфейс, то тут скорее притензии не к шарпам, а к тем языкам, где такое можно писать.

Цитата D_KEY @ 26.08.19, 15:45

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

Тогда какой смысл в интерфейсах? В чем принципиальное отличие интерфейса от абстрактного класса в Java? В ключевом слове?

Цитата D_KEY @ 26.08.19, 15:45

Если кратко, то ты разделяешь интерфейс для клиента(не виртуальный) и для наследника/реализатора(виртуальный). Клиент работает с одними наборами методов, которые реализуются посредством другого набора методов, которые предоставляет наследник или тот, кто реализует интерфейс. Хорошо ложится на такие паттерны, как шаблонный метод.

Ясно, да встречал такое. Правда не знал что это NVI паттерн.

Сообщение отредактировано: Wound - 26.08.19, 16:35

[D_KEY]

Цитата Wound @ 26.08.19, 16:32

Тогда какой смысл в интерфейсах? В чем принципиальное отличие интерфейса от абстрактного класса в Java? В ключевом слове?

В интерфейсе нельзя иметь поля. Для интерфейсов возможно множественное "наследование".

[Wound]

Цитата D_KEY @ 26.08.19, 16:39

В интерфейсе нельзя иметь поля. Для интерфейсов возможно множественное "наследование".

Нда. Тогда какой смысл в абстрактных классах?

[D_KEY]

Цитата Wound @ 26.08.19, 16:45

Тогда какой смысл в абстрактных классах?

Я не пишу на java практически, но мне кажется, что абстрактные классы нужны для общего кода в конкретной иерархии, грубо говоря. Но тут пусть java-программисты скажут.

Но я честно говоря не очень-то вижу принципиальную разницу между интерфейсами в C# и в Java. Дефолтную реализацию методов добавили не так давно в java. Может и в C# добавят.

[D_KEY]

Цитата D_KEY @ 26.08.19, 16:54

Может и в C# добавят.

Да, так и есть Default implementations in interfaces

interface ILogger
{
    void Log(LogLevel level, string message);
    void Log(Exception ex) => Log(LogLevel.Error, ex.ToString());
}

[Wound]

Цитата D_KEY @ 26.08.19, 16:56

Да, так и есть Default implementations in interfaces

Ну тогда, ИМХО, абстрактные классы уйдут в прошлое. Потому что не совсем понятно зачем они нужны. Разве что для красоты иерархии наследования, и то я сомневаюсь
Ведь проще будет использовать интерфейсы. Я так понимаю, народ перечитал SOLID принципов и начал везде и всюду писать интерфейсы, даже там, где нужен абстрактный класс. В итоге это вышло вот в такую херню(взято из твоей ссылки): https://docs.microsoft.com/ru-ru/dotnet/csh...embers-versions

Цитата

На основе этих интерфейсов команда может собрать библиотеку для удобства работы клиентов своих пользователей. Их целью было более полно взаимодействовать с существующими клиентами и повысить уровень связи с новыми.

Пришло время перейти к библиотеке для следующего выпуска. Одна из востребованных возможностей — добавление скидки за лояльность для клиентов, размещающих большое количество заказов. Это новая скидка лояльности применяется каждый раз, когда клиент делает заказ. Специальная скидка является свойством каждого клиента. Каждая реализация ICustomer может задавать различные правила для скидки лояльности.

Наиболее удобный способ добавления этой функции — расширить ICustomer методом для применения любых скидок лояльности. Это предложение по разработке вызвало проблемы среди опытных разработчиков. "Интерфейсы являются неизменяемыми после выпуска! Это критическое изменение!" В C# 8.0 добавлены реализации интерфейсов по умолчанию для обновления интерфейсов. Авторы библиотеки могут добавлять новые элементы интерфейса и реализации по умолчанию для этих элементов.