Здравствуйте, ahahah, Вы писали:

M>>>>>Такой программист отправляется пешим ходом в первый класс. Потому что у нормального программиста будет метод «ПовернутьНа90Градусов(по-или-против-часовой)», общий для всех фигур (на плоскости), но реализуемый по-разному разными фигурами
S>>>> Угу осталось добавить вокруг какой точки. Для прямоугольного треугольника это может быть только одна точка,

A>>>С какого перепугу только одна?
S>>То есть можно одновременно поворачивать вокруг двух точек?

A>Где я говорю про одновременно?

S>>>> Спасибо за предложение. Пошел учиться

A>>>Именно. Это, вообще-то, общая задача, одинаково решаемая для любых многоугольников: поворот фигуры на N градусов вокруг точки Z. Но только школьникам хочется реализовывать никому не нужный специальный метод «повернуть-треугольник-на-90-градусов», рассказывая сказки про «ах-ах-ах, в прямоугольном треугольнике только одна точка, вокруг которой он может поворачиваться».
S>> А зачем N градусов если известно положение рядом стоящей фигуры.

A>Потому что это — общая задача, одинаково решаемая для любого многоугольника. Что из выделенного тебе непонятно?

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

S>> Сколько свободного пространства останется если к стророне прямоугольника присоединиться углом а не стороной.

A>Какая разница? Это останется задачей «повернуть многоугольник на N градусов вокруг точки Z».
Это будет не оптимальеым т.к. задача раскроя N элементов на М листах является NP полной задачей и её нужно оптимизировать.

A>>Потому что это — общая задача, одинаково решаемая для любого многоугольника. Что из выделенного тебе непонятно?

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

Не зависит. У тебя стоит ровно одна задача, применительно к фигуре: повернуть эту фигуру. Вычислением, на сколько градусов повернуть, и относительно какой точки повернуть, будет заниматься другой код.

S>>> Сколько свободного пространства останется если к стророне прямоугольника присоединиться углом а не стороной.

A>>Какая разница? Это останется задачей «повернуть многоугольник на N градусов вокруг точки Z».
S> Это будет не оптимальеым т.к. задача раскроя N элементов на М листах является NP полной задачей и её нужно оптимизировать.

Причем тут задача раскроя? В этой подветке идет речь о повороте некой фигуры на какое-то количество градусов. Специально для тебя напоминаю контекст:

S> Метод Начертить будет один для всех. А вот метод ПовернутьТреугольникНа90Градусов только для треугольника.

Такой программист отправляется пешим ходом в первый класс. Потому что у нормального программиста будет метод «ПовернутьНа90Градусов(по-или-против-часовой)», общий для всех фигур (на плоскости), но реализуемый по-разному разными фигурами

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

Все. Никакого идиотизма типа ПовернутьТреугольникНа90Градусов не надо.

Здравствуйте, ahahah, Вы писали:



A>Причем тут задача раскроя? В этой подветке идет речь о повороте некой фигуры на какое-то количество градусов. Специально для тебя напоминаю контекст:
Ты ветку почитай, дам совсем другой контекст. О специализации фигур используя их особенности для оптимизации алгоритмов. Так например окружность можно вертеть до ума помрочения вокруг своей оси.

A>>Причем тут задача раскроя? В этой подветке идет речь о повороте некой фигуры на какое-то количество градусов. Специально для тебя напоминаю контекст:
S> Ты ветку почитай, дам совсем другой контекст. О специализации фигур используя их особенности для оптимизации алгоритмов. Так например окружность можно вертеть до ума помрочения вокруг своей оси.

Безотносительно ветки и ее контекста метод « ПовернутьТреугольникНа90Градусов» является бредом.

Здравствуйте, Serginio1, Вы писали:

S>Я уже это объясняю неделю. Но здесь упирается в то что так оно вроде и есть, а дай конкретную реализацию. И зачем разные фигуры если достаточно одной. Итд.
S>Или наследую прямоугольник в квадрат и наоборот.

Потому как задачу обсуждаете абстрактно. Реализовывали бы что-то конкретное — сразу бы нашли решение.
Как вариант, "квадрат" можно вообще рассматривать как предикат, вычисляемый надо прямоугольником. А вопросы разного поведения квадратов и прямоугольников можно решать на уровне классов, которые с ними должны работать, а не запихивая методы в сами квадраты и прямоугольники.

Здравствуйте, Ziaw, Вы писали:

Z>Эта ветка еще раз подтверждает, что ООП дает столько свободы действий для создания хрупкого кода, что никаким DSL'ям не снилось. И ничего, работает ведь, мейнстрим.

IMHO, эта ветка показывает, что большинство людей, пыьающихся на практике применять ООП ни ухом ни рылом в теме не волокут. Так что с ДСЛями будет тоже самое. Соответственно, или инструменты будут мегапрочными на тему защиты от дураков, или не взлетит

Здравствуйте, Erop, Вы писали:

E>IMHO, эта ветка показывает, что большинство людей, пыьающихся на практике применять ООП ни ухом ни рылом в теме не волокут.

Ну да. И это ничуть не мешает им применять наследование, например.

E>Так что с ДСЛями будет тоже самое. Соответственно, или инструменты будут мегапрочными на тему защиты от дураков, или не взлетит

Что у нас есть такого магапрочного из инструментов для ООП? Или оно не взлетело?

Здравствуйте, _Obelisk_, Вы писали:

_O_>Здравствуйте, Serginio1, Вы писали:

S>>Я уже это объясняю неделю. Но здесь упирается в то что так оно вроде и есть, а дай конкретную реализацию. И зачем разные фигуры если достаточно одной. Итд.
S>>Или наследую прямоугольник в квадрат и наоборот.

_O_>Потому как задачу обсуждаете абстрактно. Реализовывали бы что-то конкретное — сразу бы нашли решение.
_O_>Как вариант, "квадрат" можно вообще рассматривать как предикат, вычисляемый надо прямоугольником. А вопросы разного поведения квадратов и прямоугольников можно решать на уровне классов, которые с ними должны работать, а не запихивая методы в сами квадраты и прямоугольники.
Еще раз приведу всем известную задачу про ДКА можно создать семейство классов отвечающее за отработку состояния с передачей управление в другой экземпляр класса отвечающий за следующее состояние.
Можно решать эту задачу через ветвления (ПМ) и выбор алгоритма в зависимости от состояния.
Задача Прямоугольников, Окружностей, треугольников и прочих фигур например при раскрое сводится либо движений фигур вверх вниз и поворотов учитывая не пересечения с ближайшими фигурам, и оптимум на минимум свободной площади. (Или максимум остатка свободной площади когда элементов не хватает для полного заполнения). Так зная характер ломанной образованной уже расположенных фигур можно выработать стратегию расположения
конкретной фигуры с минимумом движений этой фигуры. Например прямоугольники располагаются параллельно сторонам, окружность рассполагается с центром в точке равным радиуса перпендикуляра к сторонам сверху и слева.
Треугольники тоже будут располагаться параллельно сторонам прямоугольников. Дальше уже сложнее, но специализацию можно выбрать для элементарных фигур. имеющие один виртуальный метод (интерфейса) РасположитьФигуруОтносительноРасположенныхФигурИКраёвЛиста(Данные)

Вот пример http://lemarse.spb.ru/products/cut_leather/parmel_marker.png где можно отловить закономерности расположения фигур.

Здравствуйте, Ziaw, Вы писали:

E>>Так что с ДСЛями будет тоже самое. Соответственно, или инструменты будут мегапрочными на тему защиты от дураков, или не взлетит

Z>Что у нас есть такого магапрочного из инструментов для ООП? Или оно не взлетело?
Как что? поддержка в языках, в IDE, есть несколько объектных библиотек, навязывающих правильный дизайн приложения, патерны, в конце концов. И, тем не менее, в среднем в программах вокруг меня ООП применяют зря (без такого применения было бы лучше)...

Здравствуйте, Erop, Вы писали:

E>Как что? поддержка в языках, в IDE, есть несколько объектных библиотек, навязывающих правильный дизайн приложения, патерны, в конце концов.

Это не причина взлета ООП, а его следствие.

Здравствуйте, _Obelisk_, Вы писали:



_O_>Потому как задачу обсуждаете абстрактно. Реализовывали бы что-то конкретное — сразу бы нашли решение.
_O_>Как вариант, "квадрат" можно вообще рассматривать как предикат, вычисляемый надо прямоугольником. А вопросы разного поведения квадратов и прямоугольников можно решать на уровне классов, которые с ними должны работать, а не запихивая методы в сами квадраты и прямоугольники.
А что такое сами квадраты и прямоугольники? То есть будет класс конкретно работающий с квадратом и отдельный класс работающий с прямоугольником по единому интерфейсу?
Здесь речь идет, что все фигуры являются наследниками Фигуры у которой есть массив точек учитывающий кривизну между точками.
При этом частные фигуры обладают формулами описания (эллипс, окружность, сплайны), а также особенностями взаимного расположения сторон. Например резать такие фигуры можно по массиву точек или формулам, а вот располагать на листе согласно их особенностей через единый интерфейс.