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

S>Но вообще лучше убрать Option — иначе будем обсуждать иной вопрос, а не сабжевый.

ну уберите и получите сразу уменьшение количества строк. И код будет уже сравним как минимум с С++.

S>Но вот взять базовый класс и вирт. функции с реализацией по умолчанию — в Rust для каждой из них нужно будет писать минимум 1 строчку кода для каждой функции в наследнике. Если, конечно, нет придумать спец. атрибут.

почему? И в Rust можно для характеристики прописать какой-то метод по default.

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

S>В цитате-то OK, но очень удивительно, как читая правильные вещи, вы не понимаете что это и где это в вашем коде.

Да я не думая даже написал — если поправят — то лучше запомню.

А в чем фейспалм тут: https://rsdn.org/forum/flame.comp/8601327.1

Автор: so5team
Дата: 18.09.23

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

S>Выводы какие? Даже на простейшем примере видно удобство ООП.

C# Затачивался под winforms.
rust и ++ из другой лиги.
ps ооп в расте лично мне понравилось. trait это как интерфейс и расширение в одном флаконе.

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

Р>ps ооп в расте лично мне понравилось. trait это как интерфейс и расширение в одном флаконе.

P.P.S. traits в rust во многом сделаны по подобию классов типов из хаскеля. Названия терминов только более человеческие. Вот, например, trait object, вы не поверите, это что-то из разряда "existential quantification" в хаскеле, если я сам уже не забыл и не стал путаться в хаскелевской терминологии, а это возможно

p.p.p.s. Название написал со второй попытки — таки перепутал

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

S>Видно что ООП языки — примерно одинаковой компактности, в то время как язык без ООП даже на простейшем примере потребовал писать почти в 2 раза больше строк кода.

Хм, а у меня на C чуть покороче получилось:

#include <stdio.h>
int main()
{
    printf("Text=text\nIsChecked=1\n");
    return 0;
}

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

G>Хм, а у меня на C чуть покороче получилось:

На C будет примерно так:

#include <stdio.h>
#include <stdbool.h>

// Определение базовой структуры Widget
typedef struct Widget {
    char* ControlName;
    char* ControlId;
    void (*Render)(struct Widget*);
} Widget;

void Widget_Render(Widget* widget) {
    printf("%s=%s\n", widget->ControlName, widget->ControlId);
}

// Определение структуры TextEditWidget
typedef struct {
    Widget base;
    char* Text;
} TextEditWidget;

void TextEditWidget_Render(Widget* widget) {
    TextEditWidget* self = (TextEditWidget*)widget;
    Widget_Render(widget);
    printf("Text=%s\n", self->Text);
}

// Определение структуры CheckWidget
typedef struct {
    Widget base;
    bool IsChecked;
} CheckWidget;

void CheckWidget_Render(Widget* widget) {
    CheckWidget* self = (CheckWidget*)widget;
    Widget_Render(widget);
    printf("IsChecked=%s\n", self->IsChecked ? "true" : "false");
}

int main() {
    TextEditWidget textWidget = { { "Text1", "1", TextEditWidget_Render }, "text" };
    CheckWidget checkWidget = { { "Check1", "2", CheckWidget_Render }, true };

    Widget* widgets[2];
    widgets[0] = (Widget*)&textWidget;
    widgets[1] = (Widget*)&checkWidget;

    for(int i = 0; i < 2; i++) {
        widgets[i]->Render(widgets[i]);
    }

    return 0;
}

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

S>На C будет примерно так:


И не лень тебе было портировать эту простыню, лучше б подумал немножко, что тебе хотели сказать.

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

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

G>
G>И не лень тебе было портировать эту простыню, лучше б подумал немножко, что тебе хотели сказать.

Мне стоило лишь отдать приказ — и за меня все сделал раб мой GPT. Заняло 10 сек. моего времени.

G>Мой код делает ровно тоже, что и твой. И проще и удобнее сопровождать.

Но ведь смысл кода — продемонстрировать возможности языка по реализации Liskov substitution principle.

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

С этим, конечно, спорить просто глупо.

Лично я считаю, что полновесный ООП уместен в малом числе случаев. Я вообще не припоминаю, когда последний раз я бы писал какую-то иерархию классов, кроме как для удовлетворения идиотского фреймворка.

Поэтому ООП я могу сравнить с такой фичей интересной, под названием "множественная диспетчеризация". В ООП выбор реализации метода зависит от типа первого аргумента this. Это одиночная диспатчеризация. Множественная диспатчеризация расширяет этот выбор до произвольного числа аргумнентов. В частности есть известный паттерн Визитёр, который, используя одиночную диспатчеризацию (к примеру C++, как в классической книге Четырёх) реализует двойную диспатчеризацию (ну и по аналогии можно реализовать произвольную диспатчеризацию). И там, где у языка с двойной диспатчеризацией будет очень простой код, этот самый Визитёр городит огромную кучу дополнительного кода.

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

По поводу ООП такого консенсуса нет, это я готов признать. Но своё мнение я высказал.

Лично я считаю полезным подмножеством ООП интерфейсы, наследование интерфейсов, реализации. Также может быть полезен синтаксический сахар, для замены наследования реализаций композицией. Вот это подмножество действительно полезно и часто применимо. А вот добавлять в это подмножество полновесное наследование реализаций (или, не приведи господи, множественное наследование реализаций) — лишнее. Вреда больше, чем пользы. И, что забавно, Go, Rust как раз и реализуют указанное подмножество.

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

vsb>Лично я считаю полезным подмножеством ООП интерфейсы, наследование интерфейсов, реализации...А вот добавлять в это подмножество полновесное наследование реализаций (или, не приведи господи, множественное наследование реализаций) — лишнее.

Э... А нет ли здесь противоречий? Или в первом предложении под словом "реализации" подразумевалось не 'наследование реализации'?

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

S>>Выводы какие? Даже на простейшем примере видно удобство ООП.
Р>C# Затачивался под winforms.

Тогда уж Ява, что, согласитесь, абсурдно.

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

vsb>>Лично я считаю полезным подмножеством ООП интерфейсы, наследование интерфейсов, реализации...А вот добавлять в это подмножество полновесное наследование реализаций (или, не приведи господи, множественное наследование реализаций) — лишнее.

S>Э... А нет ли здесь противоречий? Или в первом предложении под словом "реализации" подразумевалось не 'наследование реализации'?

Подразумевалось "интерфейсы", "наследование интерфейсов", "реализации".

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

vsb>>>Лично я считаю полезным подмножеством ООП интерфейсы, наследование интерфейсов, реализации...А вот добавлять в это подмножество полновесное наследование реализаций (или, не приведи господи, множественное наследование реализаций) — лишнее.

S>>Э... А нет ли здесь противоречий? Или в первом предложении под словом "реализации" подразумевалось не 'наследование реализации'?

vsb>Подразумевалось "интерфейсы", "наследование интерфейсов", "реализации".

Понятнее не стало. А что такое "реализации" в контексте ООП?

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

vsb>>Подразумевалось "интерфейсы", "наследование интерфейсов", "реализации".

S>Понятнее не стало. А что такое "реализации" в контексте ООП?

Вот пример на Java. На С++ интерфейс это класс без данных и с полностью виртуальными методами.

// интерфейс
interface MyInterface1 {
   void foo();
}

// наследование интерфейсов
interface MyInteface2 extends MyInterface1 {
  void bar();
}

// реализация
class MyClass implements MyInterface2 {
  @Override void foo() {}
  @Override void bar() {}
}

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

vsb>>>Подразумевалось "интерфейсы", "наследование интерфейсов", "реализации".

S>>Понятнее не стало. А что такое "реализации" в контексте ООП?

vsb>Вот пример на Java. На С++ интерфейс это класс без данных и с полностью виртуальными методами.

Что такое интерфейсы в Java понятно. Просто странно, что наличие такой штуки, как "реализация интерфейса" рассматривают как особенность ООП, да еще и положительную особенность.