Вопросы от "чайника" - страница 128
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Не забудем ;)
Вы лучше вместо перегрузки операторов множественное наследование замутите. Гораздо нужнее.
Вы лучше вместо перегрузки операторов множественное наследование замутите. Гораздо нужнее.
Хорошо написали - замутите :) Как раз множественное наследование это и делает.
Неделю назад принимал участие в дискуссии "множественное наследование vs. агрегирование", и агрегирование одержало убедительную победу
Неделю назад принимал участие в дискуссии "множественное наследование vs. агрегирование", и агрегирование одержало убедительную победу
Ну да, писать километр оберточного кода для каждого класса-имплементации гораздо лучше и эффективнее. И быстрее намного.
Особенно если интерфейсов под десяток.
Но ссылку киньте, ознакомлюсь на досуге.
К сожалению, этого не планируется. На данный момент рассматриваем только возможность наследования классов от структур.
Очень бы пригодилось. И ещё указатели на структуры. Причём не обязательно их (структуры) делать динамическими. Главное чтоб сортировать можно было индексный массив вместо самих структур.
// Структуры во многих случаев нежелательно заменять классами. Они экономные (нет таблицы виртуальных методов) и содержат "сплошные" данные.
Ну да, писать километр оберточного кода для каждого класса-имплементации гораздо лучше и эффективнее.
Но ссылку киньте, ознакомлюсь на досуге.
Насчет обертки - согласен, но чаще всего она выступает еще и в роли фасада или адаптера, т.е. видоизменяет интерфейс агрегируемого класса.
Ссылку кинуть не могу, это было внутрифирменное обсуждение в скайпе с участием около тридцати заинтересованных людей.
Насчет обертки - согласен, но чаще всего она выступает еще и в роли фасада или адаптера, т.е. видоизменяет интерфейс агрегируемого класса.
Это от взгляда зависит. Можно сказать что агрегация в данном случае -- костыль, т.к. множественное наследование намного прозрачнее и удобнее и с т.зр. логики, и с т.зр. кодинга.
А можно пример того, как ваша фирма справляется с ромбовидными иерархиями?
Это от взгляда зависит. Можно сказать что агрегация в данном случае -- костыль, т.к. множественное наследование намного прозрачнее и удобнее и с т.зр. логики, и с т.зр. кодинга.
А можно пример того, как ваша фирма справляется с ромбовидными иерархиями?
Ромбовидные иерархии - это, если я не ошибаюсь, как раз и есть продукт использования множественного наследования.
Вы можете привести какой-нибудь жизненный пример, когда вам встречалась необходимость построения и имплементации ромбовидных иерархий?
Ромбовидные иерархии - это, если я не ошибаюсь, как раз и есть продукт использования множественного наследования.
Вы можете привести какой-нибудь жизненный пример, когда вам встречалась необходимость построения и имплементации ромбовидных иерархий?
У человека есть рука, нога и всякие другие органы, они построены из клеток которые построены из атомов, набор атомов конечен, а вот их наборы огроменные.
все органы имеют разное назначение, но все вместе они человек. Люди бывают разные, и могут иметь разные профессии итд.
Те мы начали с множества, от которого наследуется клетка, те сошлись в один класс, потом снова разошлись на органы и снова сошлись в класс человек, и снова разошлись по профессиям.
Ромбовидные иерархии - это, если я не ошибаюсь, как раз и есть продукт использования множественного наследования.
Нет, это продукт проектирования. От использования средств языка не зависит.
Вы можете привести какой-нибудь жизненный пример, когда вам встречалась необходимость построения и имплементации ромбовидных иерархий?
С ходу нет, но использовал и не раз. Причем практически без вариантов.
Как по мне, так написание костыльных оберток уже само по себе весомый аргумент.