>2k16
>ООП

>>885320
С++ - OOP(хотя тут можно забить);
JAVA - OOP;
C# - OOP.

Оно энивэйнужно.

>>2k16
>>ООП

Эдак эти дебилы до Common Lisp дойдут.
Со всеми лямбдами и MapReduce которые в нём уже дохуя лет как.
Это не разум, это мода блять.

>>885325
>С++ - OOP
И сразу нахуй. Более уёбищной реализации и искажения всей идеи ООП мир не видовал. Но так как кресты сами по себе - нагромождение недоразумений, то для типичной крестобляди это может быть даже не очевидно.

>>885314 (OP)
>А унаследовать от двух классов - нет.
Как в крестах, чтоб потом разруливать ромбовидные наследования - развлечение для дегенератов. К тому же в 2016 даже в джяваговнах есть трейты/функциональные интерфейсы, так что все твои предьявы invalid. Иди лучше проспись.

>>885339
В институте всё делал на CLOS, наследования работали, порой и на ромб было похуй.

>Иди лучше проспись

Нет, уже 6 утра.

Нахуй не нужно.
Наследование вообще в принципе в 90% случаев может быть заменено на композицию без особых проблем.

>>885370
Дык "расширение функциональности" же.

>>885359
В лиспе ромба не бывает.

>>885325
С++ - мультипарадигма
ЖАБА - говно
C# - мультипарадигма

> Эдак эти дебилы до Common Lisp дойдут.
Ты уже проебан незнанием ничего, кроме ООП и функциональщины.

>>885424
>Дык "расширение функциональности" же.
Хуй ты расширишь класс с более 1 предком, ничего не сломав.

>>885314 (OP)
Давай поясню за .NET и C#. C# работает на CLR, CLR допускает множественное наследование тот же CLR/C++ или элементарно на уровне MSIL. На самом деле в C# возможно множественное наследование, но не возможно ромбообразное(оно не поддерживается на уровне CLR), а так как все классы наследуют от System.Object, то используюя только C#, любое множественное наследование - ромбообразное. Если хочешь использовать множественное наследование, то гугли, способы реализации там точно были, но в целом это плохая практика.

>>885547
>тот же CLR/C++

Там в это могут неуправляемые классы только.

>>885314 (OP)
ТЕБЯ МЯГКО НАМЕКАЮТ ЧТО НИЧЕГО КРОМЕ ИНТЕРФЕЙСОВ ИСПОЛЬЗОВАТЬ НЕ РЕКОМЕНДУЕТСЯ

>>885614
Ясен пень.
Эти бляди не могут, в виду отсутсвия, юзать другое.
Вот и НИНУЖНО.

>>885669
Давай пример где множественное наследование будет выигрывать у интерфейсов, а то балабол

>>885671
При наследовании мы реализацию наследуем, а интерфейс говорит тебе "ЭЙПЕТУХСДЕЛАЙКАЭТО".

И вот петуханы с синдромами утёнка и стокгольмским клепают лишний код и кудахчут о том как же хорошо.

И да, давай ка пример где интерфейсы выигрывают.

>>885673
жырно зелено
переиспользователь мамкин, кроме класса Figure на лабах по жяве в своей нищей шараге ты нихуя не переиспользовал никогда.

множественное наследование не нужно.
интерфейсы не нужны.
абстрактные методы тоже не нужны.
private разрешает методам родителя быть вызванным в потомках.
инкапсуляция ломается на раз-два.

привет вам из мира руби, сверх-высокоровнего-яп, и т.д. и т.п.

>>885684
в руби есть интерфейсы, только ты их сам описываешь и выносишь в примеси и абстрактные методы там реализуются и используются в рельсах. привет ApplicationController, ApplicationModel, ApplicationView. Инкапсуляцию это дисциплина а не стена от индусов, если не будешь писать нормальные интерфейсы и под ними закрытые методы то ты пидор

>>885688

> в руби есть интерфейсы, только ты их сам описываешь.

То что я могу написать велосипед, не значит что в языке руби есть этот велосипед из под коробки.

>>885692

> реализуются и используются в рельсах

причем здесь рельса, кловун? см. выше.

>>885692
Ой блять даже говорить с тобой не буду дебил ты ебаный. Ты хоть на первую работу устроился уже?

>>885696

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

p.s. если бы в руби были абстратные классы из-под коробки, то у такого костыля как https://rubygems.org/gems/abstract/
небыло 6кк закачек, кловун.

p.p.s. на EuRuKo 2016 Матц говорил об интерфейсах в контекте руби. посмотри кловун.

p.p.p.s 100к

p.p.p.p.s а теперь идешь нахуй.

>>885707

> абстратные классы

опечатался, методы конечно же.

>>885707
Матц это она.
То есть на первую работу устроился уже? Ну малаца дальше работай старательно пару лет и может поумнеешь. 6кк закачек там потомучто в руби вкатились такие специалисты как ты. Если ты не можешь написать метод и в нем написать raise и тебе для этого надо ставить гем, то ты именно что объектный слесарь. Тебе надо на уровне языка новый кейворд добавить чтобы это костылем перестало быть?

class ArtistCowboy
/thread

>>885314 (OP)
Разве "предпочитайте композицию наследованию" - не один из основных принципов ООП?
https://en.wikipedia.org/wiki/Composition_over_inheritance

>>885711

> Матц это она.

прекрати, содомит)))

https://en.wikipedia.org/wiki/Yukihiro_Matsumoto

Общаться по тезисам которые выдумал ты, но описал их так, словно они мои не буду. Живи с миром в своём rails мирке, друг)

>>885730
но я не пишу на рельсах :3
А про метц я говори Sandi Metz, которая продвигает ооп идеи у рубистов. Матцумото не особо то и хороший программист, как и дизайнер языков.
Я пишу на функциональных языках и ору с того как ты говоришь что тебе не нужны интерфейсы и что в руби они костыльные. В руби они самые что ни на есть честные, чисто модуль с функциями который ты подмешиваешь в другие классы. Но если ты такое не понимаешь то это твои проблемы. Абстрактный метод реализовать как нехуй, это метод в миксине который кидает ошибку. В классе куда ты его подмешаешь ты должен будешь его переопределить.

>>885547
> Давай поясню за .NET и C#. C# работает на CLR, CLR допускает множественное наследование

А разве в C# есть множественное наследование классов? Насколько я знаю, такой трюк работает только с интерфейсами.

>>885751

> А про метц я говори Sandi Metz

Ты даже не понял о ком идет речь)))

> ору с того как ты говоришь что тебе не нужны интерфейсы и что в руби они костыльные. В руби они самые что ни на есть честные

Такой смешной))) Интерфейсы в руби не честные или нечестные. Из-под коробки их нет. Хочешь, пишешь свой миксин, который будет ко-ко-ко абстрактным, ко-ко-ко кидать экспепшены, если он (миксин) включен в класс, но не реализован; и т.п. штуки.

> Абстрактный метод реализовать как нехуй.

Это неважно, тезис в том что абстрактного метода нет из-под коробки.

Все что ты можешь, это говорить: 'это _просто сделать_ поэтому и некостыльно'. Мастер аргументации)))

Но факт остается фактом, в одном случае ответственность за проебанный вызов лежит на тебе, а в другом — тоже на тебе, но есть помощник в виде компилятора и стандартов языка, что не даст забыть отрезать тебе свои ручки)

>>885370
>Наследование вообще в принципе в 90% случаев может быть заменено на композицию без особых проблем.
Поясните за эту фразу. Уже сколько раз ее слышал в подобных тредах, но так и не могу уяснить нахуя это вообще нужно? В чем профиты композиции перед наследованием? Почему плохо - пользоваться встроенными в язык инструментами и зачем надо изобретать свои?

>>885370
>в 90% случаев
>я нихуя не разбираюсь в этом, но напишу-ка я цифру с потолка, чтобы мой высер казался убедительнее

>>886155
https://www.youtube.com/watch?v=XgoldEoK-Rw&index=7&list=PLPIzp-E1msrYicmovyeuOABO4HxVPlhEA
Даже индус понимает в быдлокодинге больше тебя.
Можешь смотреть с 34 минуты, если влом всё смотреть.

>>886708
Видеотуторы для петухов, уходи.

>>886713
Что, английский не можешь осилить?

>>885822
Нахуя в динамическом языке абстрактные методы искаропки?

>>886724
Сиди и смотри как быдло то что читается раз в 5 быстрее.

>>886764
Нахуя тебе вообще что-то из коробки? Пиши на голом си, или вообще на ассемблере.

>>886764

хотя бы затем, чтобы я не плакал, видя как очередной сердобольный пишет код вида:

##
# abstract
def method
end

А еще отсутствие стандарта в языке или его библиотеке порождает дохуя вариаций на тему.

В жопу такой way и ооп.

Хотя бы AbstractCallError < StandartError добавить в основную библиотеку, а то приходится использовать позорный NoImplementError, что не отражает сути проблемы.

---

Дали полиформизм, дали обрубленную инкапсуляцию, а дальше ебись как хочешь, Вась. Отсюда рождаются кловуны как этот >>885751, что незнают что писать +чисто модули+ с (абстрактными) 'функциями' в руби -- идиотизм чистой воды.

---

А динамические природа языка меняет ооп, привнося duck typing, что частично компенсирует отсутствие интерфейсов в чистом их виде. Но не объянять все это школьнику выше.

>>887170
Придурок блять, что такое дак тайпинг? И что такое класс типов? и нахуя нужны интерфейсы? Наверное затем, что мы хотим чтобы некоторые разные типы(классы) обладали некоторым одинаковым интерфейсом, но реализовывали свое поведение по разному. ООП у него меняется. твое ебланское представление об ооп основано на таких ублюдках как джава и прочие поделия. ООП это когда ты описываешь систему в виде объектов, которые обмениваются сообщениями. Дак тайпинг это и есть правильный интерфейс, сообщение одно, объекты разные. А ну пиздуй назад в свою джава пещеру.

>>887377
Вот я(оп) и спрашивал, шо за хуета ОО-языками.
Стандарты ЯЗЫКОВ есть. Понятие полноты(по Тьюрингу) есть.
А вот ООП каждый гондобит как могёт.

>>887398
Причем, популярные но кастрированные поделия(жаба\шарп к примеру) влияют на умы юзеров, и вот уже костыли это догма.

>>887399
А в чем проблема-то? ПИЧОТ от того что ваши абстрактные теоретические понятия никому не нужны, а нужны простые прикладные решения?

Вообще у вас какое-то обострение нынче, в половине тредов идет ООП срач, в котором участвует какой-то дурачок (не ты ли?) верещащий что джава-с++ это не ооп, и вообще все в меире все делают неправильно

Есть тайпклассы. Все остальное нахуй