История изменений

Компромисс возможен не в правильном использовании, а в ограниченном контексте,

И чем это отличается одно от другого?

когда проблема сводится к деталям и специфике, а не базовым принципам.

А когда проблема сводится к базовым принципам вместо специфики частного случая?

Я против protected ничего не имею, это как раз допустимый компромисс. Но это не инкапсуляция.

Ну так C# гибкий. Можно опцианально выбирать только private и будет полная инкапсуляция.

Неопределённость возникает из-за приблизительного использования понятий. «Частичная инкапсуляция», «приблизительная истина» и т.д.

Да с чего ты взял, что при дизайне руководствовались стремлением к полной инкапсуляции, а не выгодам, получаемым от частичной инкапсуляции при её правильном использовании?

В области познания и программирования нет ничего вреднее, чем приблизительное.

Дооо, поэтому индустрия LLM показывает такой бурный рост.

«Database может отправлять запросы, но ещё ты можешь унаследоваться и вмешаться в пул задач» — это не частичная инкапсуляция.

От реализации не зависит?

Наследование - это один из инструментов. Требования проекта разве регламентируют его использование?

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

А если родительский класс - часть тиражируемой ООП библиотеки?

Все люди вообще мало в чём согласны друг с другом. Но раз уж в язык добавили множественное наследование, значит кем-то оно считается полезным и на это есть основания, которые нужно принять к сведению, а не избегать.

Если следовать твоей логике, то раз множественное наследование не добавили ни в Java, ни в C#, то значит оно очень многими считается бесполезным? Вообще разве можно натягивать частный случай крестов на все остальные?

so, it’s even more true for multiple inheritance.

Т.е. таки вредная?

Думаю, что если мы решаем добавить наследование в язык, то множественное наследование необходимо, но его не добавляют только потому что его легко использовать не по назначению (обычный code reuse, плохо обдуманные иерархии) и сложно использовать по назначению. Это справедливо и для наследования, но в меньшем масштабе.

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

придумали тупицы, используют идиоты, разработчики C++ дураки».

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

Ошибка подразумевает, что её можно было избежать. А как?

Разве я не показывал, как?

Допустим, у нас много сущностей, на которые можно подписаться — не просто Event и Day, а ещё десяток других сущностей. Например, это какая-то внутренняя система для журналистов — им нужно быть постоянно в курсе различных сущностей, внутренних и внешних. Мы вынесли подписку в общий родительский класс, а в дочерних классах неизбежно привязались к особенностям родительского класса.

Когда количество сущностей больше единицы, и тем более, если их неопределённо много, то используют динамические структуры данных, а не статическое наследование?

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

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

Архитектурные ошибки — слишком широкое понятие. Что я должен был архитектурно сделать, чтобы избежать описанных проблем?

Изучить ООП дизайн? Почитать соответствующие книги?

Важно то, что в моих примерах проблемы возникают из-за наследования.

Забиваю микроскопом гвозди, но они плохо забиваются и микроскоп почему-то потом плохо работает?

Я их не игнорирую, я их не вижу. Я только вижу «неправильно», «не подходит», «ошибочно», «неудачно», «опыт».

Поэтому сделал вывод, что микроскоп ущербен?

Всем было бы проще, если бы ты предложил решения проблем. «Нужно было использовать наследование вот так и проблем бы не было».

Вася, учи матчасть! Читай книжки про ООП.

Да, я думаю, что таких инструментов нет. Только если человек сам погрузится в конкретный ограниченный пример (не целый домен и желательно не огромный фреймворк).

SonarQube, Codacy, Code Climate, Codebeat, CKJM, CodeMR, NDepend, CppDepend

Компромисс возможен не в правильном использовании, а в ограниченном контексте,

И чем это отличается одно от другого?

когда проблема сводится к деталям и специфике, а не базовым принципам.

А когда проблема сводится к базовым принципам вместо специфики частного случая?

Я против protected ничего не имею, это как раз допустимый компромисс. Но это не инкапсуляция.

Ну так C# гибкий. Можно опцианально выбирать только private и будет полная инкапсуляция.

Неопределённость возникает из-за приблизительного использования понятий. «Частичная инкапсуляция», «приблизительная истина» и т.д.

Да с чего ты взял, что при дизайне руководствовались стремлением к полной инкапсуляции, а не выгодам, получаемым от частичной инкапсуляции при её правильном использовании?

В области познания и программирования нет ничего вреднее, чем приблизительное.

Дооо, поэтому индустрия LLM показывает такой бурный рост.

«Database может отправлять запросы, но ещё ты можешь унаследоваться и вмешаться в пул задач» — это не частичная инкапсуляция.

От реализации не зависит?

Наследование - это один из инструментов. Требования проекта разве регламентируют его использование?

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

А если родительский класс - часть тиражируемой ООП библиотеки?

Все люди вообще мало в чём согласны друг с другом. Но раз уж в язык добавили множественное наследование, значит кем-то оно считается полезным и на это есть основания, которые нужно принять к сведению, а не избегать.

Если следовать твоей логике, то раз множественное наследование не добавили ни в Java, ни в C#, то значит оно очень многими считается бесполезным? Вообще разве можно натягивать частный случай крестов на все остальные?

so, it’s even more true for multiple inheritance.

Т.е. таки вредная?

Думаю, что если мы решаем добавить наследование в язык, то множественное наследование необходимо, но его не добавляют только потому что его легко использовать не по назначению (обычный code reuse, плохо обдуманные иерархии) и сложно использовать по назначению. Это справедливо и для наследования, но в меньшем масштабе.

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

придумали тупицы, используют идиоты, разработчики C++ дураки».

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

Ошибка подразумевает, что её можно было избежать. А как?

Разве я не показывал, как?

Допустим, у нас много сущностей, на которые можно подписаться — не просто Event и Day, а ещё десяток других сущностей. Например, это какая-то внутренняя система для журналистов — им нужно быть постоянно в курсе различных сущностей, внутренних и внешних. Мы вынесли подписку в общий родительский класс, а в дочерних классах неизбежно привязались к особенностям родительского класса.

Когда количество сущностей больше единицы, и тем более, если их неопределённо много, то используют динамические структуры данных, а не статическое наследование?

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

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

Архитектурные ошибки — слишком широкое понятие. Что я должен был архитектурно сделать, чтобы избежать описанных проблем?

Изучить ООП дизайн? Почитать соответствующие книги?

Важно то, что в моих примерах проблемы возникают из-за наследования.

Забиваю микроскопом гвозди, но они плохо забиваются и микроскоп почему-то потом плохо работает?

Я их не игнорирую, я их не вижу. Я только вижу «неправильно», «не подходит», «ошибочно», «неудачно», «опыт».

Поэтому сделал вывод, что микроскоп ущербен?

Всем было бы проще, если бы ты предложил решения проблем. «Нужно было использовать наследование вот так и проблем бы не было».

Вася, учи матчасть! Читай книжки про ООП.

Да, я думаю, что таких инструментов нет. Только если человек сам погрузится в конкретный ограниченный пример (не целый домен и желательно не огромный фреймворк).