ООП. Иерархия геометрических фигур.

Это - символ веры культа карго.

Это ынтерпрайз разработка, там тимлид умную книгу прочитал про проектирование ооп и пошел внедрять. Или нуб прочитал букварь и пошел проектировать. Проектов, скатившихся в development hell, которые начали с классов и иерархии полно, их сложно поддерживать и переделывать. Ты приходишь в контору на работу и там такой проект, где круг наследуется от квадрата, ромб от прямоугольника, а эллипс от треугольника. И всё натыкано костылями, а от рассказов «нахер так жить» все разводят руками, переписывать долго дорого, непонятно, что будет в итоге, а работать надо. Лучшею иерархию ты предложить не можешь, да и вообще в рамках недоязычка ничего годного предложить не можешь в принципе. То, что жабаооп - сранина, выше уже подтвердили, но на что его менять не рассказали.

ну вот зачем ты с козырей, А :)

Видимо прошлого треда и общей формулы площади людям нехватило

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

Есть такая проблема, что у тебя class Путь будет разрастаться по мере разработки. Получится типичный god object, с которым наследование и призвано бороться. А тут так получается, что использовать его нельзя, а использовать больше особо нечего.

Проектов, скатившихся в development hell, которые начали с классов и иерархии полно, их сложно поддерживать и переделывать.

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

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

Если кто-то про них будет всё знать - это похеренный принцип инкапсуляции. Зачем нам объект, который ничего не может и все пользуют его в приватные поля?

Это ынтерпрайз разработка, там тимлид умную книгу прочитал про проектирование ооп и пошел внедрять. Или нуб прочитал букварь и пошел проектировать.

Вполне возможно.

Но почему-то никто не учитывает другой фактор. Я считаю что он основной, хотя могу быть не прав.

В «ынтерпрайз», да и в обычной веб разработке все горит, а задача постоянно меняется, и надо за минимальное время модифицировать проект так, чтобы закрыть новую задачу которая внезапно возникла. На проектирование и перепроектирование времени нет, да и лень. Отсюда - «умные» книжки и зубодродительная иерархия изначально, чтобы сразу заложить возможность быстро вставлять костыли.

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

Ну а когда обеспечили легкость добавления костылей, естественно что они будут добавляться тоннами (ведь это стало проще всего) и - все в мясо.

Дев хелл из за непродуманных зависимостей, а не из за наследования. Наследование это просто частный случай зависимости.

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

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

Вывод какой? Что зависимости - это зло, которого надо избегать? Тогда и иерархии с типами надо избегать, чем гибче код, тем проще его переделать в итоге.

Есть такая проблема, что у тебя class Путь будет разрастаться

например в связи с чем? реальный кейс обозначь.

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

Да, зависимости можно продумывать это называется «архитектура», распространение изменений по коду можно ограничивать и даже менять их направление с помощью интерфейсов.

Вывод какой? Что зависимости - это зло, которого надо избегать? Тогда и иерархии с типами надо избегать, чем гибче код, тем проще его переделать в итоге.

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

Даже когда ты просто подключаешь к проекту какую нибудь либку это уже +1 зависимость. А еще у всех (почти) программ есть зависимость от ОС.

Ты угораешь? Нахер ты все это писал?

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

Не сношался бы с ооп было бы всё легко и просто. А так, теперь весь проект придется переделывать, когда надо будет найти фигуру, которая получилась в результате пересечения.

например в связи с чем? реальный кейс обозначь.

Я тебе сейчас пачку хитрожопый фигур придумаю и придётся делать для каждой isФигура как минимум.

все что непосредственно к классу Путь относится это проверки на замкнутость и самопересечение. замкнут и не самопересекается - фигура, это все что нужно знать в этом классе.

класс Фигура - проверки на впуклость и выпуклость.

класс ВыпуклаяФигура - площадь и пересечение

класс Четырехугольник - проверка на Квадрат, Ромб етц.

Хорошо. У тебя есть какой-то полигон, как узнать, что это за фигура? Создать сразу все эти классы?

весь проект придется переделывать

ты угораешь?(с) там переделок на пятачок. иерархия то правильная, просто усеченная до размеров задачи. унаследует Четырехугольники от ВыпуклыхМногоугольников, воткнет туда метод для вычисления пересечения и все дела.

Не нужна никакая иерархия. Глубокие иерархии наследования – вообще зло. Нужен один класс-интерфейс Shape с методами вроде Area(), IntersectsWith() и разные его реализации. Если реализация разных методов дублируется, то можно её вынести в отдельные общие функции безо всякого ООП.

Вообще автор темы может посмотреть код разных физических движков чтобы узнать как это ка самом деле делается для решения реальных задач.

Зачем в гуе иерархия фигур? Например? Пока я лишь вижу обсуждение диванных кукаретиков (а не практиков, хотя бы диванных) или высасывание примера из пальца (на один из которых я даже дал высосанную из пальца реализацию).

Наверняка ведь есть задачи, где нужна.

Еще один кукаретик.

Всё познается в сравнении. Хотелось бы увидеть реализацию задачи (которая не была озвучена) в других подходах.

но на что его менять не рассказали

Не на что менять. У нас есть джава - меньшее безумие из всех современных безумий. Никто не заинтересован инвестировать в исследование и разработку ЯП отвечающего духу времени. Как мне заявил один инвестор: «Это не в нашей компетенции» (с) Хотя там надо с процессоров и ОС вообще начинать…

Наследование салата от глинтвейна и наоборот противоречит принципу лисков.

Создать сразу все эти классы?

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

как узнать, что это за фигура

Это не надо знать.

Глубокие иерархии наследования – вообще зло.

обычно хватает связки интерфейс-реализация.

реже интерфейс-абстрактный класс-реализация.

еще реже требуется бОльшая глубина, но то такоэ, специфичное.

Причём здесь приватные поля? Вот например - http://algolist.manual.ru/maths/geom/polygon/area.php высчитываем площадь рандомного полигона. Для этого нужна поверхность (координаты) и понимание про полигон. Ты эту зависимость знаний будешь тащить в каждую фигуру?

Только после того, как ты положишь фигуру на поверхность можно посчитать её площадь. И фигура не может знать что такое поверхность и что такое площадь соответственно тоже не знает. Это же 2Д объект, а не Евклид в 3Д мире, чтобы уметь площадь считать.

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

«как правильно сделать иерархию фигур Евклидовой геометрии» - это некорректная постановка, поэтому что уж тут удивляться тому что у неё нет красивого ответа.

Много лет назад я пробовал Objective-C, сейчас я использую объекты в питоне и тайпскрипте (главное, без фанатизма). Вроде всё хорошо.

И ML сейчас неплохо справляется с некоторыми частными случаями таких зада. Проблема для нас, программистов в том, что ML-то справляется, а мы - нет.

ML не справляется, а аппроксимирует. Напрограммировать для геометрических кругов общий класс отображать всё полигонами из треугольников тоже можно.

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

ООП - overrated

Будто этого кто-то не знает.

в данной задачи не нужна иерархия

Я вам по секрету скажу, что нет единого метода решения всех задач.

не должен

Любая плоская фигура - это множество квадратиков требуемой для конкретной задачи степени малости. Остальное - от лукавого, абстрактное математическое баловство

Не можно, а нужно в случае сложной геометрии.

Треугольников. Квадратики хуже апроксимируют

Но это совсем другая тема, чем в топике.

Обоснуйте.

Так почти всю геометрию на компе так или иначе аппроксимируют треугольниками. Взять тот же старый OpenGL где это было явно видно.

Глинтвейн нельзя помещать в контейнер «водитель».

Да и svyatozar - поц.

Кто обзывается тот сам так называется.

тебе название не понравилось

Наоборот, очень нравится %)

Я тебе сейчас пачку хитрожопый фигур придумаю и придётся делать для каждой isФигура как минимум.

Я думаю тред нужно было начать с кода без ООП, «как надо», а то тут критикуют ООП, но ничего не предлагают.

Можно. Отлично помещается.

Но это вызывает критическую ошибку. Т.е. не проходит незаметно.

Поведение классов и подклассов должно различаться. Главное, чтобы интерфейс сохранялся.

Вопрос тут не в интерфейсе.

ничего не понял, но очень интересно

Ну вот, значит, я не зря писал))

Трудно не согласиться.

Я уточню. Эти ООЯП очень даже хороши сами по себе. Но они устарели. Причем таким образом, что того, что им должно прийти на смену, не особо то и наблюдается. Проблема в системе базовых типов. ООЯП получают её от железа, и это в подавляющем большинстве случаев — CPU, это целые числа, это FP и весьма минималистичная модель памяти (я бы хотел видеть аппаратную поддержку ассоциативной памяти, но это отдельная тема).

Вот есть смартфоны, и есть Mac M1, где уже в качестве стандартного компонента идут матричные процессоры. И есть те же APU на PC. Но наши любимые ООЯП со всеми их методологиями тут могут разве что предложить методы моделирования тех же матриц. Отстой.

ML — не решение, потому что ML — это «черный ящик», и у моделей отсутствует и композициональность, и интерпретируемость. Они холистичны, т.е. рассматриваются и применяются целиком «как есть». Из них нельзя «надергать кода в свой проект».

И вот проблема в том, что с одной стороны у нас ООЯП, которые годня только для некоторого класса символьных задач. А с другой — черный ящик ML. И между ними по сути ничего нет.

Нету концептуального мостика от системы типов ООЯП к продвинутым высокоуровневым репрезентациям.

А нужен ли такой язык?

Этот вопрос можно переформулировать так: нужна ли человек-интерпретируемость моделей, выводимых методами машинного обучения? Сами AI/ML-щики говорят, что да. Потому что к результатам работы ML в противном случае нет доверия.

Одна из причин, почему наше программирование живо, здорово и процветает, в том, что оно управляемо и предсказуемо в смысле конечного результата. Чего нельзя сказать про тот же ML. Мы видим какие-то громкие заявления, прозрачные намеки на скорые прорывы. Но чего-то меня всё еще не возит self-driving taxi. DL is overpromising and underdelivering.

Короче, да, такой язык нужен. Нам нужны новые концепции программирования, способные эффективно охватить и дать в распоряжение инженера вновь появляющееся оборудование.

В этом смысле мне нравится новое направление software-hardware co-design. Это когда мы можем «делать железо под софт». А не как сейчас — софт под железо.

ООЯП получают её от железа, и это в подавляющем большинстве случаев — CPU, это целые числа, это FP и весьма минималистичная модель памяти

Не вижу проблем. Делайте виртуальную машину и будет какая захочется система типов и модель памяти. Если виртуальная машина станет успешной, то под неё и железо потом могут сделать.

В смысле отстой? Сейчас жавистов позовём.

Я там выше пояснил уже. Я, если что, сам джавист и Буча читал еще в 90-х. А напечатанная мною на матричном принтере методичка по ООП на паскале стала reader's choice в общаге нашей кафедры в инстике.

Проблема с ООЯП в том, что появился ИИ и начал оттягивать к себе спекулятивный интерес всякими разговорами про Software 2.0: заменит ли ML программистов.

Локальные технические проблемы конкретно Java в том, что из-за её модели памяти там трудно делать data-oriented design. То, что Java использовали для написания дата-платформ в прошлом десятилетии, так это всё ценой титанических усилий и костылей вида sun.misc.Unsafe, использование которого — это один сплошной UB в продакшене.

Ты понял, что тема - развод, но походу не понял в чём развод. Тут в самом деле не нужны классы квадраторомбов, правильный ответ прост и состоит из одной расхожей тут фразы.

Развод конкретно этой задачи в том, что не определено поведение объектов «геометрическая фигура». Народ на это покупается и кидается строить иерархии «по умолчанию», так как они это понимают интуитивно.

Грубо говоря, если мы понимаем геометрически фигуры как элементы построения изображения (движок рендеринга) — это одна задача. Если мы хотим сделать физический движок — это другая задача и нам тут нужно фокусироваться на «иерархиях взаимодействия» фигур. Если мы хотим написать код, который легко менять (future-proofness), то это третий, совершенно новый аспект поведения одних и тех же объектов «геометрическая фигура».

Совместить все эти аспекты в рамках одной линейной иерархии нельзя. Тут нужно переходить к DoD и работе с репрезентациями объектов, а ООП (иерархии классов) уже будет возникать динамически над репрезентациями.