Насчёт "равномерности распределения". Масса чёрной дыры — понятие довольно условное. Дело в том, что гравитационное поле чёрной дыры на большом удалении такое же, как поле некоего сферического тяжёлого объекта в ньютоновской (нерелятивистской) гравитации. Вот массу этого эквивалентного тяжёлого объекта и называют массой чёрной дыры. Но она, эта масса, не образована веществом чёрной дыры, вещества там вообще нет, если оно и было — то упало в сингулярность. Про заряд сказать не могу ничего, только что "всё сложно".
Просто есть три ступени развития программиста: до-ООП, ООП и после-ООП. И хотя для человека, который сам находится на средней ступени (ООП), код после-ООП может быть неотличим от кода до-ООП, реально они очень разные. А некоторые достигнув стадии после-ООП по привычке называют и считают свой код ООП, хотя это уже нечто иное.
Если как в Rust можно объявить интерфейс и тут же его реализовать для нужных типов — то да, вполне эквивалентно получается. К сожалению в том же C# так нельзя и реализация всех интерфейсов должна быть одном модуле с объявлением класса, что несколько ограничивает.
Я пробовал — уже сейчас наследование можно довольно неплохо эмулировать сочетанием portrait и моего dynamic-cast. Чуть-чуть многословно и есть трудности с изменением иерархии (так как каждый наследник должен перечислять всех предков при объявлении), но жить можно.
Очень просто. Делается алгебраический тип данных и далее можно определять сколь угодно много точек с полиморфным поведением без всякой связи с объявлением самого типа.
Разве это проблема ООП, а не плохого программиста, который создает непонятные иерархии?
Именно проблема ООП, которое позволяет и подталкивает к такому. В большинстве случаев наследование реализации вообще не нужно, но у ООП-программистов нет идиосинкразии к этому, а у кого есть — значит он уже начал расти за пределы привычного ООП-подхода.
то же как раз кейс, где ошибочно использовать абстрактный класс, а нужно использовать интерфейс
Класс, интерфейс — неважно, проблема остаётся. Причём проблема элементарно решаемая средствами функционального программирования.
1. Ухудшение структуры кода при наследовании реализаций.
При неограниченном наследовании реализаций структура кода "размягчается". Возникают странные иерархии классов, не соответсвующие архитектуре, а существующие только чтобы что-нибудь "перекрыть" с не менее странными классами если взглянуть отстранённо. Лезут анипаттерны вроде "Паблик Морозов".
2. Неадекватное повышения связанности ООП кода.
Так как полиморфизм обеспечивается механизмом виртуальных методов, то для каждого места, где нужно полиморфное поведение, необходимо завести абстрактный базовый метод. В резльтате базовый класс полнится заголовками методов, существование которых оправдано только кодом "где-то там", а реализации либо превращаются в год-классы либо обрастают монструозной архитектурой, иногда даже с депенденси инжекшеном.
Насчёт "равномерности распределения". Масса чёрной дыры — понятие довольно условное. Дело в том, что гравитационное поле чёрной дыры на большом удалении такое же, как поле некоего сферического тяжёлого объекта в ньютоновской (нерелятивистской) гравитации. Вот массу этого эквивалентного тяжёлого объекта и называют массой чёрной дыры. Но она, эта масса, не образована веществом чёрной дыры, вещества там вообще нет, если оно и было — то упало в сингулярность. Про заряд сказать не могу ничего, только что "всё сложно".
А что, у Бугаенко были хорошие и правильные идеи? На мой взгляд у него были идеи как сделать код ужасным с точки зрения архитектуры.
А что для вас "длина строки"? Количество кодепойнтов? Количество графем? Ширина графем в моноширинном шрифте?
Тяжёлые операции рекомендуется запускать мимо тредпула с помощью опции
LongRunning.Просто есть три ступени развития программиста: до-ООП, ООП и после-ООП. И хотя для человека, который сам находится на средней ступени (ООП), код после-ООП может быть неотличим от кода до-ООП, реально они очень разные. А некоторые достигнув стадии после-ООП по привычке называют и считают свой код ООП, хотя это уже нечто иное.
Если как в Rust можно объявить интерфейс и тут же его реализовать для нужных типов — то да, вполне эквивалентно получается. К сожалению в том же C# так нельзя и реализация всех интерфейсов должна быть одном модуле с объявлением класса, что несколько ограничивает.
Я пробовал — уже сейчас наследование можно довольно неплохо эмулировать сочетанием
portraitи моегоdynamic-cast. Чуть-чуть многословно и есть трудности с изменением иерархии (так как каждый наследник должен перечислять всех предков при объявлении), но жить можно.Очень просто. Делается алгебраический тип данных и далее можно определять сколь угодно много точек с полиморфным поведением без всякой связи с объявлением самого типа.
Именно проблема ООП, которое позволяет и подталкивает к такому. В большинстве случаев наследование реализации вообще не нужно, но у ООП-программистов нет идиосинкразии к этому, а у кого есть — значит он уже начал расти за пределы привычного ООП-подхода.
Класс, интерфейс — неважно, проблема остаётся. Причём проблема элементарно решаемая средствами функционального программирования.
Две проблемы не раскрыто.
1. Ухудшение структуры кода при наследовании реализаций.
При неограниченном наследовании реализаций структура кода "размягчается". Возникают странные иерархии классов, не соответсвующие архитектуре, а существующие только чтобы что-нибудь "перекрыть" с не менее странными классами если взглянуть отстранённо. Лезут анипаттерны вроде "Паблик Морозов".
2. Неадекватное повышения связанности ООП кода.
Так как полиморфизм обеспечивается механизмом виртуальных методов, то для каждого места, где нужно полиморфное поведение, необходимо завести абстрактный базовый метод. В резльтате базовый класс полнится заголовками методов, существование которых оправдано только кодом "где-то там", а реализации либо превращаются в год-классы либо обрастают монструозной архитектурой, иногда даже с депенденси инжекшеном.