> Я указал на то, что если будет метод "расстояние между точкой и прямой" - то его по
> канонам С++ нужно будет обязательно выполнить либо в классе "прямая", либо в классе
> "точка", либо в классе "фигура".Ты путаешь каноны ООП с канонами C++. Современный C++ не любит наследование и с подозрением относится к ООП. Rust, который писался во многом по мотивам C++, вообще не имеет наследования. C++ его таки использует, но называть принципы ООП каноничными для C++? Вы на C++ вообще пишите, или на C с классами?
> Твой пример с generic расстоянием между фигурами мне ни о чём не
> сказал. Ну допустим будет много реализаций. Что это меняет? Если тебе
> предложат написать такую программу, ты что, откажешься? Не функцию, а программу.
> Расстояние между фигурами. Фигур 10 типов. Это задача для неудачников по
> твоему?
Я тебе привёл пример ситуации, когда нужны методы для двух классов. Это единственное, что пришло мне в голову и требует метода для двух классов. Ну, точнее, не то чтобы требует, но как-то возникает желание использовать наследование для выбора нужной реализации функции, а значит круто было бы реализовать это методами классов, а не просто глобальной функцией. Всё остальное, что мне приходит в голову, либо сводится к тому, что методом класса оказывается обычная глобальная функция, с красивым *this указателем промежь аргументов, либо там вполне достаточно наследования от одного класса, либо ещё что-нибудь.
> Если тебе предложат написать такую программу, ты что, откажешься? Не функцию, а программу.
> Расстояние между фигурами. Фигур 10 типов. Это задача для неудачников по
> твоему?
Да. В такой постановке (надо именно этих десять фигур, и именно законченной программой) задача может возникнуть только как задача для студенческой курсовой. Если ты зарабатываешь денег написанием курсовых для студентов, то как программист ты неудачник.
В реальных задачах всегда есть tradeoffs между функциональностью кода, сложностью его, производительностью, потреблением памяти и рядом других параметров. Здесь же, совершенно определённо видна безумная квадратичная зависимость количества реализаций методов от количества примитивов, а это значит, что надо очень и очень аккуратно обходиться с подбором этих примитивов. Потому что если нам когда-нибудь вдруг понадобится ещё один, причём конкретно понадобится, станет ясно что без него никуда, а у нас к тому моменту будет уже два десятка примитивов, то нам придётся писать ещё 21 реализацию метода distance. Да, это будет ради одного и самого главного примитива, но 21 реализацию. А если при этом ещё каждая из этих реализаций окажется нетривиальной, то написание и отладка этих методов может потребовать нескольких недель.
Поэтому сама идея неудачна и имеет смысл вернуться к исходной задаче, которая породила такую идею, и переосмыслить её ещё раз, поискать какую-нибудь менее очевидную, но более реализуемую идею.
