я не понимаю о чем ты вообще )

ВСЕЕ. ИМХО. Я небуду с тобо спорить, ты дьявол😂

архитектура, дефолт реализация... структуры ))

ок ;D

К тому же я по расту только документацию полистал, я могу ошибаться. Но такое первое впечатление.

Там выше пост, что типа раст топ потому что умеет дефалт методы в своем крейте, а ооп нахер не нужон. Я к этому писал.

думал про шарп

си шарп

уточню

Нет. В расте например есть трейт Iterator. Для его имплементации нужно реализовать метод next. А автоматически реализуется с полсотни методов. Т.е. дефолтные методы, которые зависят от метода next. Всякие map, filter, fold, sort, collect, чего там только нет.

А что еще надо чтобы был бохатый? Отсутствие одной фичи - наследования - это не бедность. В голанге кстати и этого меньше. Ни итераторов (в расте есть), ни дженериков (в расте есть), лямбд вроде тоже нет (в расте есть лямбды. Да да, вы не ослышались, в системном языке есть лямбды и даже с замыканиями), всякие enum'ы с любым содержимым в расте, чего там только нет. Сахара может и побольше чем даже в той же джаве, чуточку меньше чем в котлине

Я не писал, что ООП нахер не нужон. Я писал, что трейтами с фичей дефолт методов можно писать без наследования (ООП != наследование) и без отдельно интерфейса и отдельно реализации в виде паттерна Стратегия, как это было в ролике. Схема взаимосвязей получается плоской и несвязной. Еще банда четырех говорила: "не наследуйте реализацию, наследуйте интерфейс". Большую часть паттернов проектирования на расте написать получится, и даже выглядеть будет как на современном ЯП, а не как если бы ты пытался эти паттерны реализовать на Си.

Вопрос исчерпан

#ithumor

>наследование
>фича
>сравнил с дефалтным методом в интерфейсе
Да ты толсто тролишь😂😂😂

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

Если честно нет🌚 Забайтился от текста. Здравый смысл есть да и видимо раст не так прост. Оке.

В ролике четко обозначена проблема наследования.

Ты думаешь, что у тебя связь C extends B extends A, а потом оказывается, что надо X extends B but not A and C, Y extends A and C bot not B, ты пытаешься создавать деревья классов типа XAB, YAC и т.д.  и у тебя всё летит к чертям, и надо переписывать пол-проекта.

Т.е. наследование создаёт прибитую гвоздями связь между интерфейсом и реализацией. Поэтому в проекте на века нужно разделить на интерфейс и класс с реализацией этого интерфейса. И потом ты когда создаешь конкретный класс, пишешь (немного ООП-псевдокода)
class MyX implements A, B {
   AImpl aImpl = new AImpl();
   BImpl bImpl = new BImpl();
   
   int foo() { return aImpl.foo(); }
   int foo2() { return aImpl.foo2(); }
   int bar() { return aImpl.bar(); }
   int bar2() { return aImpl.bar2(); }

   void spam() { bImpl.spam(); }
   void spamspam() { bImpl.spamspam(); }
   void eggs() { bImpl.eggs(); }
   void eggsAB() { bImpl.eggsAB(); }

}

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

Но тут другая проблема: слишком много шаблонных методов делегирования
И нормальные дефолт методы это решают.

Пишешь

interface A {
   AImpl getAImpl();

   int foo() { return getAImpl().foo(); }
   int foo2() { return getAImpl().foo2(); }
   int bar() { return getAImpl().bar(); }
   int bar2() { return getAImpl().bar2(); }

}

interface B {
   BImpl getBImpl();

   void spam() { getBImpl().spam(); }
   void spamspam() { getBImpl.spamspam(); }
   void eggs() { getBImpl().eggs(); }
   void eggsAB() { getBImpl().eggsAB(); }
}

Весь боилерплейт делегирования остался в интерфейсе, в классе нужно только объявить геттер к объекту.


class MyX implements A, B {
   AImpl aImpl = new AImpl();
   BImpl bImpl = new BImpl();
   AImpl getAImpl() { return aImpl; }
   BImpl getBImpl() { return bImpl; }
}

class MyOtherX implements A, B {
   AImpl aImpl = new OtherAImpl();
   BImpl bImpl = new OtherBImpl();
   AImpl getAImpl() { return aImpl; }
   BImpl getBImpl() { return bImpl; }
}

class MyY implements A, C {
   AImpl aImpl = new AImpl();
   CImpl cImpl = new CImpl();
   AImpl getAImpl() { return aImpl; }
   CImpl getCImpl() { return cImpl; }
}

class MyZ implements A, B, C {
   AImpl aImpl = new AImpl();
   BImpl bImpl = new OtherBImpl();
   CImpl cImpl = new CImpl();
   AImpl getAImpl() { return aImpl; }
   BImpl getBImpl() { return bImpl; }
   CImpl getCImpl() { return cImpl; }
}


И ты можешь наштамповать огромное количество самых разнообразных классов просто создавая класс, геттер к реализатору и имплементируя интерфейс. Реализатор действует по принципу паттерна Статегия.
И не будет деревянной связи. И не придется думать, типа че делать, мне нужно животное, которое умеет ходить, потом которое умеет ходить и летать, потом которое умеет ходить и плавать, мне что создавать AbstractWalkingAnimal, AbstractWalkingFlyingAnimal, AbstractWalkingSwimingAnimal? А если мне в будущем понадобится добавить животным атаку, мне каждому варианту добавлять наследника AbstractAttack***Animal и AbstractNotAttack***Animal?

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

Почему в шарпах нужно кастовать объект к интерфейсу, чтобы вызывать его методы, я хз. В расте не нужно.

.

Но в с# нет множественного наследования ...
Но вы можете создать абстрактный класс с виртаульным методом и перезагружать атаку сколько влезет.

абстрактный для всех зверюшек