Программирование, т. 5.1.

В джаве как бы есть множественное наследование, только оно реализовано через интерфейсы.

у тебя есть класс А и класс Б

ты хочешь получить класс Ц который включал бы функционал А и функционал Б

вообще множественное наследование - это рак мозга

В джаве как бы есть множественное наследование, только оно реализовано через интерфейсы.

у тебя есть класс А и класс Б

ты хочешь получить класс Ц который включал бы функционал А и функционал Б

вообще множественное наследование - это рак мозга

обычная технология

обычная технология

серьезно обычная?

часто на работе это используешь?

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

как ты думаешь, почему этой параши нет в жаве?

и?

и?

что и? я задал 3 вопроса и сделал одно утверждение. а ты просто написал и?

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

и то, если в шарпе даже для интерфейсов есть явная реализация интерфейсов

Всем пис

http://tonsky.livejournal.com/281876.html

Java почти не уступает C/C++ по скорости

Так-то полностью согласен с Рубишем. Если у тебя возник повод наследовать от двух классов - у тебя проблемы с кодом. И более того: язык который дает такую возможность как-то сам подталкивает разработчика писать криво, предоставляя фактически костыль

Так-то полностью согласен с Рубишем. Если у тебя возник повод наследовать от двух классов - у тебя проблемы с кодом. И более того: язык который дает такую возможность как-то сам подталкивает разработчика писать криво, предоставляя фактически костыль

имеешь понятие о 'is a' и 'implemented in terms of' ?

 

хз че вы взъелись на множественное наследование. Ну есть оно и есть. Кто-то им пользуется, кто-то нет. Не такая уж и плохая вещь. Другое дело что косячить с ней можно достаточно серьезно, вот ее и убрали ее нахуй отовсюду.

Да и вообще сейчас наследование применяют налево-направо, надо это или нет, только потому что патерн прописал использовать. Хотя на самом деле оно нужно только максимум в 10% случаев в которых его применяют, вводя кучу ненужных кастов - просто потому что так заведено.

обычная технология

серьезно обычная?

часто на работе это используешь?

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

как ты думаешь, почему этой параши нет в жаве?

 

А джава внезапно откровения ЯП?

Множественное наследование порой помогает в системном программировании.

Так-то полностью согласен с Рубишем. Если у тебя возник повод наследовать от двух классов - у тебя проблемы с кодом. И более того: язык который дает такую возможность как-то сам подталкивает разработчика писать криво, предоставляя фактически костыль

имеешь понятие о 'is a' и 'implemented in terms of' ?

 

хз че вы взъелись на множественное наследование. Ну есть оно и есть. Кто-то им пользуется, кто-то нет. Не такая уж и плохая вещь. Другое дело что косячить с ней можно достаточно серьезно, вот ее и убрали ее нахуй отовсюду.

Да и вообще сейчас наследование применяют налево-направо, надо это или нет, только потому что патерн прописал использовать. Хотя на самом деле оно нужно только максимум в 10% случаев в которых его применяют, вводя кучу ненужных кастов - просто потому что так заведено.

я так понимаю, что твое is a и implemented in terms of - это как раз наследует и имплементирует. то-есть первое - это наследование, а второе имплементация интерфейса.

в целом я все это писал в ключе "почему жава лучше для изучения ооп".

ну в целом так-то есть практики, которые указывают, когда надо использовать наследование, а когда не надо.

на некоторых собеседованиях прямо напрямую спрашивают: почему декорирование лучше наследования в чистом виде

 

А джава внезапно откровения ЯП?

Множественное наследование порой помогает в системном программировании.

в системном программировании? ты серьезно? системное программирование процентов на 90+ процедурное

жава - это переосмысление с++ во многом. поставь еще рядом си шарп, как переосмысление жавы и ставь вопросы: почему они решили так сделать? может быть они не правы. если не правы - то почему?

с# = java+cpp

по крайней мере так майкры описали свой язык. в целом согласен. хотя это дело такое.

множественное наследование порой помогает в системном программировании. задачи разные бывают. В целом да, процедурное.

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

Изменено 6 июля 2015 пользователем mixogen

с# = java+cpp

по крайней мере так майкры описали свой язык. в целом согласен. хотя это дело такое.

множественное наследование порой помогает в системном программировании. задачи разные бывают. В целом да, процедурное.

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

как оно помогает в системном программировании? какие задачи оно решает?

какая разница есть там сборщик мусора или мусор ты собираешь сам, если тебе надо учить ООП?

семантика отталкивает? это чем же?

с# = java+cpp

по крайней мере так майкры описали свой язык. в целом согласен. хотя это дело такое.

множественное наследование порой помогает в системном программировании. задачи разные бывают. В целом да, процедурное.

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

 

по поводу множественного наследования: если я правильно понимаю вообще идеи создания языков от с++ выше (objective C, Java, C#, все эти мутанты от майкров для ВС), все ведется к снижению уровня вхождения. Т.е. максимально упростить сам язык, за счет прощения как можно более грубых ошибок и простой семантики. а покрывать это все растущими возможностями железа(в большей степени) и новыми идеями в ЯП (в меньшей). больше людей пишет, больше контента генерируется, больше спроса на ИДЕ, облачные вычисления, хостинг, интернет-маркеты(продавать же где то свои "творения" надо). это не плохо и не хорошо, это закономерно.

 

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

 

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

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

ты так и не написал какие проблемы оно решает

Так-то полностью согласен с Рубишем. Если у тебя возник повод наследовать от двух классов - у тебя проблемы с кодом. И более того: язык который дает такую возможность как-то сам подталкивает разработчика писать криво, предоставляя фактически костыль

имеешь понятие о 'is a' и 'implemented in terms of' ?

 

хз че вы взъелись на множественное наследование. Ну есть оно и есть. Кто-то им пользуется, кто-то нет. Не такая уж и плохая вещь. Другое дело что косячить с ней можно достаточно серьезно, вот ее и убрали ее нахуй отовсюду.

Да и вообще сейчас наследование применяют налево-направо, надо это или нет, только потому что патерн прописал использовать. Хотя на самом деле оно нужно только максимум в 10% случаев в которых его применяют, вводя кучу ненужных кастов - просто потому что так заведено.

я так понимаю, что твое is a и implemented in terms of - это как раз наследует и имплементирует. то-есть первое - это наследование, а второе имплементация интерфейса.

в целом я все это писал в ключе "почему жава лучше для изучения ооп".

ну в целом так-то есть практики, которые указывают, когда надо использовать наследование, а когда не надо.

на некоторых собеседованиях прямо напрямую спрашивают: почему декорирование лучше наследования в чистом виде

Ну не совсем так.. в С++ есть разные модификаторы наследования: public, protected, private, virtual.

Обычное наследование в понимании шарпов - это is a = public. Как объект именно Является другим объектом. Интирфейсы - это public со всеми методами virtual (..) = 0; Которые обязательно должны быть перегружены.

in terms of - это когда объект реализует другой объект, по логически не являеся имеено им. К примеру можно именть много объктов, каждый из которых предоставляет набор функционала, который нужен для существования этого объекта. В жаве мы бы просто их включили в реализацию. В С++ в принципе можно сделать так же, да и многи так и делают. Но тут вступают в роль темплейты, для возможность получения информации о типах во время компиляции.

К примеру

class CustomWidget : public ShareableWidget, private EnableLogging<CustomWidget >, private vritual AllocInterprocessList<ShareableWidget, 10> { .... }

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

И да, все эти классы от которых наследуемся - могут иметь собтвенные данные.

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

Изменено 6 июля 2015 пользователем Tinplz

Ну не совсем так.. в С++ есть разные модификаторы наследования: public, protected, private, virtual.

Обычное наследование в понимании шарпов - это is a = public. Как объект именно Является другим объектом. Интирфейсы - это public со всеми методами virtual (..) = 0; Которые обязательно должны быть перегружены.

in terms of - это когда объект реализует другой объект, по логически не являеся имеено им. К примеру можно именть много объктов, каждый из которых предоставляет набор функционала, который нужен для существования этого объекта. В жаве мы бы просто их включили в реализацию. В С++ в принципе можно сделать так же, да и многи так и делают. Но тут вступают в роль темплейты, для возможность получения информации о типах во время компиляции.

К примеру

class CustomWidget : public ShareableWidget, private EnableLogging<CustomWidget >, private vritual AllocInterprocessList<ShareableWidget, 10> { .... }

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

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

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

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

В джаве как бы есть множественное наследование, только оно реализовано через интерфейсы.

у тебя есть класс А и класс Б

ты хочешь получить класс Ц который включал бы функционал А и функционал Б

вообще множественное наследование - это рак мозга

https://ru.wikipedia...ограммирование)

 

А вот использование примесей:

 

https://github.com/eigengo/opensourcejournal/blob/master/cake-pattern/cake.md

Ну не совсем так.. в С++ есть разные модификаторы наследования: public, protected, private, virtual.

Обычное наследование в понимании шарпов - это is a = public. Как объект именно Является другим объектом. Интирфейсы - это public со всеми методами virtual (..) = 0; Которые обязательно должны быть перегружены.

in terms of - это когда объект реализует другой объект, по логически не являеся имеено им. К примеру можно именть много объктов, каждый из которых предоставляет набор функционала, который нужен для существования этого объекта. В жаве мы бы просто их включили в реализацию. В С++ в принципе можно сделать так же, да и многи так и делают. Но тут вступают в роль темплейты, для возможность получения информации о типах во время компиляции.

К примеру

class CustomWidget : public ShareableWidget, private EnableLogging<CustomWidget >, private vritual AllocInterprocessList<ShareableWidget, 10> { .... }

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

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

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

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

Я не о модификаторах доступа к полям и методам, а о модификаторах доступа к наследуемому классу. Хотя жто может я чего-то не знаю.

А интерфейсы в шарпах вроде позволяют только объявлять паблик методы.

 

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

Как я уже говорил, то можешь просто взять и запулить кусок функционала в свой объект.

допустим:

 

class C : private A<C> {}

 

template <typename Derived>

class A : protected shareable_routines, private interprocess routines {

private:

ShareableInterprocess<Derived> shareable_obj;

static ShareableChunkManager shareble_chunk_manager;

 

protected:

void write_shareable(Derived derived) = 0;

void read_shareable(Derived* derived) = 0;

void register_shareable() {... }

void unregister_shareable() {...}

 

// addition support methods

....

 

~A(){..}

}

 

Тут в А ты просто пулишь необходимый функционал из необходимых тебе классов, для внутренних имплементаций

И обязуешь реализовать только 2 метода, давая функционал shareable_routines.

Кроме этого у А есть собственное состояние, которое он может менять.

 

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

Альтернативы конечно есть в шарпах и жаве.

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

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

https://ru.wikipedia...ограммирование)

 

А вот использование примесей:

 

https://github.com/e...pattern/cake.md

ну это же не множественное наследование лол.

кстати в жаве последней вроде бы реализовали дефолтную имплементацию интерфейсов

 

Тут в А ты просто пулишь необходимый функционал из необходимых тебе классов, для внутренних имплементаций

это называется делегированием или бриджом в шаблонах. то-есть вместо того, чтобы инкапсулировать какой-то класс через поле или свойство ты наследуешься? ты серьезно? я говорю о чистоте
Изменено 6 июля 2015 пользователем rubish