Может все невзгоды можно перенести и с одной мамой, но что тогда делать папе. А что если это аккаунты? Как нормально сделать защищающего папу администратора и любящую маму модератора? А если ещё один вид бабушка - менеджер модератор? А если остался один дедушка и менеджер модератор и единственный рутовый администратор-защитник обездоленного ребенка - юзера? Можно конечно все выстроить в линеечку! А может под каждую роль аккаунта по новому классу? Так чтоб для каждого генерала делать свой баян? Можно по конкретнее что не так? А то я написал что принято одно наследования класса, а мне про мои тапки только и вспоминать! Так в чем проблема?

А ещё можно вспомнить про копирование кода между каждым аккаунтом+DRY, и тогда такой спагетти код если 200 разных ролей у которых метод на подметоде и методом погоняет. Что делать?

А что если у нас сайт получен без исходных кодов и в старой библиотеке наведен такой марафет, что даже ребенок случайно жмет format c:? Как нам перейти со старых аккаунтов на новые без полной аннигиляции?

Множественное наследование говорит о одном - о том что применен великий патерн BigPeaceOfMud. Идея в том - интерфейсов много - а родитель один. А измышления про два папа или два мама или шведская семья оставьте пожалуйста для свободной либеральной тусовке и РосАтом.

Права в наследовании в C++ могут быть разными вспомиаем private, protected , public , мало того чисто виртуальные функции могут иметь реализацию по умолчанию, чтобы не вылетать при обращении к им по исключению . Как вариант. Само по себе наследование это отличный инструмент, заменяющий агрегирование , вопрос только в умении его правильно применять. Никто же не заставляет применять наследование там , где без него можно обойтись. Верно?

Мало того что родишь один интерфейс, ты можешь ещё и определить какие методы будут public , а какие нет. Ну или например , я хочу , чтобы метод вектора operator[] () умел выбрасывать исключение outofrange как метод At() , тогда template < typename T

Class myvectir : private STD::vector

T operator [] (size_t index) { . return At(index); }

// и всё всех делов то. Получили operator [] со свойствами At , про производительность я пожалуй промолчу , но безопасность в плане исключения outofrange перешла и на operator[], он теперь тоже умеет выбрасывать outofrange, я могу перехватить исключение прямо в этом операторе и возвращать например. optional , но это уже совсем другая история:) 😁

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

Это доказывает только одно - в С++ скапливается народ который любит бисать конструкцию из условий в 10 -20 строчек. Который вместо проектирования - делает какие-то дикие заплатки на написаной на коленке системы и самолюбуются своими способностями - типа о как я могу. Как не понять - код должен быть во первых обслуживаемым. То есть он может работать 10-20 лет и быть понятен тому кто пришел чинить его в этот период.

Ну вот , как и все джависты , сейчас начнётся воспоминание про SoLID , дядюшку Боба , и совершенное забывание про Kiss например. Всё что есть в java есть в c++ , я прекрасно знаю оба языка, про код на коленке забавно да. Solid уже не так важен ИИ поймёт любой код, без проблем и прокомментирует. Могу легко обосновать что обычный массив и конструкция из switch/case будут в Стопицот раз эффективнее чем любой полиморфизм и т.д. могу доказать с цифрами и с помощью Intel vtune. Просто я умею руками разворачивать циклы и оптимизировать код га уровне ассемблера.

Да в курсе. Сам 5 лет писал на плюсах и С. И обстановку прекрасно знаю. Живите без всего в своем мире. Удачи. Только просьба со своими убеждениями в построение ник многоступенчатых не понятных схем в Энтерпрайз не лезет.

Причём тут убеждения? Энтерпрайз это не только и нестолько джава , сколько проблемно ориентированные языки rsl например, я сопровождал банковский софт писанный на rsl более 5 -лет , и писал под него модули на плюсах. Причём тут убеждения.?? Джава это весьма корявая попытка упростить c в частности. Полиморфизм времени компиляции в c это шаблоны а в java это generic-и которые по своей сути -частный случай наследования , тоесть то что в c, это полиморфизм времени компиляции, в java это суррогат который компилятор пилит в рантайме. Про сборку проектов и прочее , в c есть cmake + ninja который собирает всё мгновенно. И если честно при выборе между java(суть кастрированный c) и c естественно я выберу c++ , хотя бы просто потому что та м не надо if obj1.Equal(obj2) {} А достаточно if obj1==obj2 , там нет утечки памяти по умолчанию gс-по сути это всего лишь контролируемая утечка памяти. И да полиморфизм времени компиляции, метапрограммирование и многое другое:) Это я так , на вскидку.

Везде работает прекрасный принцип kiss - keep it simple , stupid! Сохраняй простоту -глупый. Никто из нас не может предсказывать будущее. Поэтому проектировать код с расчётом на будущее , пустая затея. Если нам , конкретно здесь и сейчас. Нужен switch , именно его и надо использовать, ненужен никакой полиморфизм там где достаточно switch/case из 5/6 пунктов, достаточно того, чтобы этот свитч помещался полностью в один экран -всё. Полиморфизмы , наследования и т.д. это костыли, мощные костыли которые применять надо очень хорошо подумав. Вот и все мои убеждения. Если мы с помощью свитча на 100% закрываем задачу, нам больше ниче говори о не нужно, как-то так. Вот и все мои убеждения. 😁

Свинарники они везде есть. И чуханы если они kiss прикрываются чуханами остаются. Вон у тебя братан в "РосАтом" коллег полно. Пишут быстро не думая - но главное много. А если там что-то глючит после этого - так фигня - пацанчик есть который ловко на приемосдаточных при необходимости заплатки ставит.

Уважаю классику. Считаю что благодаря java у нас было построено много для веба. Очень вдумчивые люди писали книги, проектировали системы, писали код. Много было сделано для упрощения кода - спасения от спагетти кода. Я написал этот пост как теоретический прием и надеялся на понимание, но объяснил область применения - аккаунты и проблемы модульности. Я не хотел чтобы была драка программистов из разных языков. Разве не замечательно, что можно если захотел сделать что-то не из java, то просто сел и написал на плюсах. Александр прав что классику забывать не стоит. Но современные проблемы гонят иногда дальше. Хотел бы оставить на проффесионалов jre надо ли добавлять в классическую java борьбу за аккаунты и модульность(интеграцию). Было бы приятно увидеть взвешенное мнение других. Рад что есть мыслители вроде Александра. Очень хотелось бы видеть java и дальше в будущем на передовой технологий особенно в проектировании. Хорошо когда люди думают!

Я рад что есть свободо мыслящие. Но не надо забывать классику java. Приятно что благодаря шаблонам в плюсах появились теории метапрограммирования и обобщенного программирования. Пусть лучше подумают создатели java про классику как Александр, и про свободу как Константин. Александр видимо имеет много опыта жёсткого бизнеса. Цените что герой жив! А Константин привык широко шагать, такие нужны среди крупных лидеров. Благодарю за разноплановое обсуждение.