LINUX.ORG.RU

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


0

0

привет всем!

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

как, по вашему, нужно/не нужно?

есть примеры хорошего использования?

есть ли чем его заменить?

спасибо за ответы! =)


>как, по вашему, нужно/не нужно?

Зависит от языка. В динамических, имхо, нужно в меньшей степени

есть примеры хорошего использования?

mixins/разложение класса на стратегии

есть ли чем его заменить?

В какой-то степени - Traits

yoghurt ★★★★★ ()

Как бы ответ на этот вопрос есть в факах у основателя С++

http://www2.research.att.com/~bs/bs_faq2.html#multiple

Do we really need multiple inheritance?

Not really. We can do without multiple inheritance by using workarounds, exactly as we can do without single inheritance by using workarounds. We can even do without classes by using workarounds. C is a proof of that contention. However, every modern language with static type checking and inheritance provides some form of multiple inheritance. In C++, abstract classes often serve as interfaces and a class can have many interfaces. Other languages - often deemed «not MI» - simply has a separate name for their equivalent to a pure abstract class: an interface. The reason languages provide inheritance (both single and multiple) is that language-supported inheritance is typically superior to workarounds (e.g. use of forwarding functions to sub-objects or separately allocated objects) for ease of programming, for detecting logical problems, for maintainability, and often for performance.

anonymous ()

И вообще, в самом расп*датом ОО языке множественное наследование отсутствует, что символизирует!

yoghurt ★★★★★ ()

> решил заняться дизайном языка программирования

Главный вопрос - зачем?

anonymous ()
Ответ на: комментарий от yoghurt

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

anonymous ()

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

Legioner ★★★★★ ()

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

annulen ★★★★★ ()
Ответ на: комментарий от yoghurt

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

lester ★★★★ ()

Проектируешь и нас же просишь помочь в этом проектировании самим сделав за тебя часть работы...
Вот ты проектируешь - ты и думай нужно оно в твоём языке или нет.
Вообще, зависит от цели языка.
Считаю что нужно. Однако реализация не проста.
Те люди, что говонят «не нужно», либо просто не занимались проектами, где оно ужас как нужно, либо не помнят уже.
К примеру, геймдев вообще без множественного наследования обрастёт велосипедами и костылями. Да и не только.
Готов поспорить что в конце ты придёшь к мысли что, как минимум, миксины нужны. А это, по сути, то же множественное наследование.
Можешь глянуть D. Там нет множественного наследования. Однако есть миксины, которые, по сути, можно использовать как наследование. Все так и говорят: «в ди есть множественное наследование, но через миксины».
В общем, сам определи что ты хочешь и так и делай.

tia ()

Почему никто не начал с того что ООП вообще не нужно т.к являет собой «римские числа» проектирования программ? И что наследование - это дилетантское переизобретение работы со множествами, в данном случае - с множествами типов?

Absurd ★★★ ()
Ответ на: комментарий от Absurd

Почему никто не начал с того что ООП вообще не нужно

я самим своим присутствием в треде молчаливо выражаю эту точку зрения

jtootf ★★★★★ ()

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

Booster ★★ ()

> решил заняться дизайном языка программирования

Уже задизайнили, начиная с 50х годов. Последний стандарт был в 90х.

CL-USER ()
Ответ на: комментарий от placement_new

Разверните, пожалуйста.

это будет 4.3, а мне ещё работать

jtootf ★★★★★ ()
Ответ на: комментарий от Absurd

>Почему никто не начал с того что ООП вообще не нужно т.к являет собой «римские числа» проектирования программ?

А что ты предлагаешь взамен объектной декомпозиции? Хаскель и классы типов?

anonymous ()
Ответ на: комментарий от anonymous

>А что ты предлагаешь взамен объектной декомпозиции? Хаскель и классы типов?

В настоящий момент я имею представление о типичной эволюции объектных абстракций во времени в типичном проекте. Оно меня не устраивает. Если бы меня в индустрии все устраивало - не писал бы я в Development.

Absurd ★★★ ()
Ответ на: комментарий от anonymous

Ну что ты не даёшь элите помечтать? Элита же себя мыслит летающей высоко в небе с Лиспом и Хаскелем, а внизу ползающие Жабы и Плюсы. В палате №6 и не такое бывает до укола галоперидола.

anonymous ()
Ответ на: комментарий от anonymous

>Элита же себя мыслит летающей высоко в небе с Лиспом и Хаскелем, а внизу ползающие Жабы и Плюсы.

Процедурный подход тоже лучше ООП.

Absurd ★★★ ()
Ответ на: комментарий от Absurd

А как выглядит настоящий процедурный подход? А то что-нибудь вроде

perform (some_object, some_action, some_data);

Суть то же ООП

yoghurt ★★★★★ ()
Ответ на: комментарий от yoghurt

Суть то же ООП

весь вопрос в том, на каком месте в списке будет имя функции; некоторым это крайне важно

А как выглядит настоящий процедурный подход?

сферический в вакууме или практический?

jtootf ★★★★★ ()
Ответ на: комментарий от jtootf

>сферический в вакууме или практический?

Хотелось бы на оба посмотреть

Хотя с практическим-то я, пожалуй, знаком, ибо простыней кода на QBasic и Pascal в детстве понаписал несколько тетрадок :)

yoghurt ★★★★★ ()
Ответ на: комментарий от theos

>>Процедурный подход тоже лучше ООП.

А они друг другу не противоречат.

ООП его выворачивает наизнанку, делая первичным интерфейс а не функционал.

Absurd ★★★ ()
Ответ на: комментарий от lester

а какой вы можете продемонстрировать?

ко мне можно на «ты». могу сферический - разбиваем модуль на процедуры, изменяющие глобальное (локальное по модулю) состояние. весь обмен данными выполняется через расшаренные области памяти, отличающиеся плоской (бинарно стандартизованной) структурой, прозрачно сериализуемой для работы с потоками ОС. поскольку по умолчанию вся обработка выполняется in-place, синхронизация выполняется по Хоару (CSP, блокировки, критические секции, семафоры, условные переменные)

в реальной жизни чисто процедурный стиль смешивается с функциональным (процедуры возвращают значения, используются указатели на функции в качестве first class object, используются структуры указателей на функции, etc)

jtootf ★★★★★ ()
Ответ на: комментарий от Absurd

ООП его выворачивает наизнанку, делая первичным интерфейс а не функционал.

то есть делает шаг от теории множеств к теории категорий

jtootf ★★★★★ ()
Ответ на: комментарий от jtootf

то есть делает шаг от теории множеств к теории категорий

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

class FaceRecongizer {
public:
  virtual double calcFaceLikeness(const TGAImage& sample1, const TGAImage& sample2) = 0;
};
Absurd ★★★ ()
Ответ на: комментарий от Absurd

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

theos ★★★ ()
Ответ на: комментарий от Absurd

Absurd

Почему никто не начал с того что ООП вообще не нужно т.к являет собой «римские числа» проектирования программ? И что наследование - это дилетантское переизобретение работы со множествами, в данном случае - с множествами типов?

Согласен! Более того. На мой взгляд средства языка должны быть отражением алгоритма в голове программиста. Страуструп в Дизайне и эволюции пишет, что не знает какое множественное наследование более правильное — виртуальное или нет. Потому что в голове нет этому аналога. Имхо, единственный повод для введения наследования — экономия на повторном написании(изменении) кода, и, если есть способ это сделать без наследования, было бы очень здорово!

А по сему к вам вопрос, какие есть менее дилетантские и более целостные концепции?

ien ()
Ответ на: комментарий от anonymous

Хаскель, кстати, идейно хорош!

Наконец-то интерфейсы оторвали от типов. Я могу работать в своем коде с любой строкой(которая удовлетворяет указанному интерфейсу), а не с конкретной.

А то у всех свои понятия о строках(char*, string, QString, CString, ...). И хрен поймешь, что лучше использовать в конкретном месте.

ien ()
Ответ на: комментарий от jtootf

jtootf

зачем?

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

ien ()
Ответ на: комментарий от ien
Имхо, единственный повод для введения наследования -- экономия на повторном написании(изменении) кода, и, если есть способ это сделать без наследования, было бы очень здорово!

А по сему к вам вопрос, какие есть менее дилетантские и более целостные концепции?

По-моему одна из таких это шаблонный метод. Да и вообще виртуальные методы.

Booster ★★ ()
Ответ на: комментарий от ien

>Наконец-то интерфейсы оторвали от типов. Я могу работать в своем коде с любой строкой(которая удовлетворяет указанному интерфейсу), а не с конкретной.

Только не говори что тебе ООП это сделать не позволяла.

theos ★★★ ()
Ответ на: комментарий от ien

>единственный повод для введения наследования — экономия на повторном написании(изменении) кода

это же является и единственным поводом для процедурного подхода. Когда-то программы писали последовательно и набивали на перфокарты))

на самом деле, наследование ни разу не противоестественно - детализация объекта

annulen ★★★★★ ()

Всего года два назад ещё считал, что нужно.

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

KRoN73 ★★★★★ ()
Ответ на: комментарий от ien

> у всех свои понятия о строках(char*, string, QString, CString, ...)

что мешает добавить соответствующий конструктор или метод доступа? в QString нет никаких проблем с тем чтобы создать объект из строки типа char* или получить char* или string из нее.

annulen ★★★★★ ()
Ответ на: комментарий от Booster

>Почему его сложно реализовать?

Миф такой распространённый :)

KRoN73 ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.