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



S>> Нет есть реальное наследование. Прямоугольник это фигура. Все её свойства никуда не делись. Но добавились часные случаи, которыми проще оперировать.
E>Ох, религия, такая вещь, упёртая. Тут ничего не поделаешь.
E>У нас, как бы стоит задача. Грубо говоря она называется оптимизация перебора, идти надо, скорее всего, через поиски каких-то частей решения, и какие-то движения в пространстве решений.
E>А ты всё время рассказываешь, что у прямоугольника есть какие-то там хитрые свойства.
E>Насколько я тебя понял, основное свойство прямоугольника -- это то, что его пожно поставит на край листа только одной из двух сторон. Но это же примитивно делается и без прямоугольника. Просто смотрим на фигуру, понимаем, что она хорошо вписываетя в прямоугольник и генерим для неё всего ДВА варианта ориентации при размещении. Потом, когда кладём её, то двигаем максимально вниз и влево, например. ФСЁ.
E>Никакого ООП, и вообще никакого много чего ещё.
E>Мало того, можно какие-то куски дерева перебора, на которых удалось получить компактное заполнение по ширене листа, например, запоминать и брать сразу кусками. Этакий кэш поддеревьев сделать. И т. д.
А вот когда у тебя алгоритм будет работать с несколькими примитивами, тебе уже нужно работать по единому интерфейсу

S>>Если угол может быть всего в двух вариациях как 0 и 90 то еще проще с ним работать.
E>Тогда и с оринигальной фигурой работать так же просто...
E>Мало того, программа получится сильно короче. Так как особо простую и выразительную логику работы с прямоугольниками вообще ен надо будет программировать. Полное отсутсвие кода проще же, чем сколь угодно простой код?..
Нет оригинальная фигура если ты её не впишешь в прямоугольник для оптимального расположения нужно выбрать положение от крайних фигур.
Для треугольника это уже 4 степени свободы.

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

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

S>>Но по сути это тоже вариант наследования.
E>По сути ты предлагаешь всё максимально запутать.

E>А я предлагаю наоборот чётко отделить данные для оптимизации переборщика от реальных форм деталей. Ин нафиг не надо уметь смешиваться...

S>>Ты видел раскрои портных? Там есть вогнутые, выгнутые, скошенные детали. Допустим у тебя есть треугольник, а рядом нужно поместить другой треугольник, так что бы общая площадь вписанная в прямоугольник была минимальна. Понятно, что они должны лежать типа 69. Здесь мин макс хорошо для описание через прямоугольник. Но вот более сложные фигуры нужно вертеть.

E>И что с того? Вертеть фигуры НЕ СЛОЖНО.
E>Правда конкретно у портных вертеть фигуры НЕЛЬЗЯ.
Почему, если не зависит от структуры Кожи или других материалов? Так скажем не портных а раскройщиков одежды.

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

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

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

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

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

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

S>> Интересно а как ты квадрат то наследовать будешь? Это вырожденный прямоугольник у которого все стороны равны. Единственное его преймущество, что нужно знать всего одну сторону.


E>В общем, здорово,ч то ветку выделили, правда стартовое сообщение какое-то непонятное вышло
E>

---

В качестве резюме обсуждения ООП в алгоритме оптимизации раскроя могу сказать такой тезис.
E>ООП должно программу улучшать. Поэтому программа с ООП должна, как минимум, быть лучше программы в стиле чистого С с типами. Так что надо прикинуть, как бы это писалось без ООП вовсе, чисто данные, структуры там, типобезопасность, то, сё. А потом попробовать понять, чем программа, с ООП прикрученным обсуждаемым образом, будет ЛУЧШЕ.

E>Если ответа на этот вопрос нет, то и ООП тут не надо.
E>Аналогичный подход касается и многих других приёмов и инструментов "улучшающих код"

Да я то полностью согласен. Вот в С++ нет разницы между структурой и классом. В Delphi Net Любой класс это наследник от Object. И вот здесь по неволе будешь использовать
Если в Delphi до определенного времени была возможность наследовать структуру, то Net это запретили, только через агрегацию.
ООП это не только полиморфизм, на который здесь упирают, но и простое наследование реализации с добавлением новых свойств. А где это использовать уже другой вопрос.
Мне в 1С даже такого не хватает.

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

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

S>>А вот здесь проблема должна решаться через возможность удаления из видимости этого свойства. Перегружать (overload )через new можно, а удалять нельзя?

Z>Наследование без полиморфизма? Весь смысл наследования в возможности алгоритмов работать с наиболее далеким предком. Все его потомки должны выполнять контракт одинаково, это LSP. New это не overload, это не перегружать, а создавать с тем же именем. В некотором смысле, new это противоположное перегрузке действие.
В большинстве случаев это как раз наследование реализации с добавлением новых свойств, типа множественного наследования

S>>>И во всех этих вариантах внешний хелпер получается уместнее.
S>> А куда мне в этот хэлпер новое свойство то ввести?

Z>Есть данные, есть алгоритмы их обработки. Свойства, очевидно, должны быть в данных. Наследовать свойства конечно можно, но надо иметь гарантию, что любой алгоритм, работающий с базовым классом будет работать корректно со всеми его потомками. А не падать в рантайме при попытке доступа к свойству. А любой предок оправдан только в случае, когда есть алгоритмы, которые работают именно с ним.
Во многих случаях работает по одному алгоритму и в языках типа 1С работает через утиную типизацию. И алгоритм падать то он точно не будет если реализован на свойствах.
В большинстве случаев, когда не нужно изменять свойства просто передается некая структура данных. А вот следить за включения нужных свойств приходится делать вручную, и создавать такие структуры тоже вручную.
Как я уже здесь писал, по свой работе в 1С неплохо было бы определять интерфейсы свойств по которым бы генерировались свойства в объекте. Причем 1 свойство могло включаться в нескольео интерфейсов (или можно вручную переопределить). А вот за реализацию можно уже делать класс хэлпер, на основании интерфеса. И можно работать как на уровне интерфейса, так и объекта с полным набором свойств.
Агрегаты и интерфейсы это тоже ООП. Так или иначе даже в той же 1С есть ООП базовый класс (Тип, вид, метаданные), иерархия справочники, документы,регистры. Внутри документов агрегацию, у которых будет одинаковое поведение для движений по регистрам.

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

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

I>>А на деле получается так — (0,0) — (1,3) это ровно один квадрат
M>

	который из них?

Я про диагонали говорил.

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

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

S>>>Ещё раз: зачем наследовать треугольник? Все нужные от него методы уже реализованы для "фигуры из N точек". Вы же не думаете, что периметр трапеции вычисляется как-то иначе, чем периметр прямоугольника?
S>>Зачем вообще вводить лишнюю сущность как фигура из трех сторон? Зачем вводить замечательные пределы итд?
S>Это вы меня спрашиваете? Вы вводите — вам и виднее.
S>Я сразу писал, что в большинстве случаев достаточно иметь один класс Shape. А вся поддержка "фигур из трёх сторон" сводится к Shape CreateTriange(lenA, lenB, lenC) и другим перегрузкам метода-конструктора.
Да нет вроде не я являюсь автором этих фигур. Их задолго до меня изобрели.
В большинстве случаев достаточно и фигуры ввиде массива точек, и вида соединения между точек прямолинейное или криволинейное. Или работать с частными случаями

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

S>Алгоритм может работать с набором примитивных фигур. Например можно собирать прямоугольники из треугольников, прямоугольников, овалов, вогнутых фигур.А затем работать с прямоугольниками.
Эти утверждения не имеют никакого отношения к наследованию.

S>Любая частная фигура по свой сути это фигура. Или это не так?
Для алгоритма размещения — нет. Для него есть только, например, прямоугольники.
Надо понимать, что никакой "сути" нету. Есть только код.

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

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

S>> Для вычисления площади достаточно просто переопределить метод получения площади.
S>Это понятно. Вопрос не в достаточности, а в необходимости. Вот у меня есть метод вычисления площади произвольного многоугольника.
S>Он мне нужен в любом случае, если я собираюсь поддерживать произвольные многоугольники. Из школьного курса математики нам понятно, что этот метод будет работать корректно для любого многоугольника, начиная с двух углов.
S>А теперь внимание, вопрос: зачем нам вообще заниматься перегрузкой этого метода в наследниках класса Polygon? Вы что, полагаете, что для квадрата этот метод будет работать как-то неправильно?
S>Или вас забавляет процесс написания кода ради кода?
S>Вот у меня код:
S>

S>public static Shape CreateRectangle(int a)
S>{
S>  return new Shape(new Point[] {{0, 0}, {0, a}, {a, a}, {a, 0}});
S>}
S>...
S>public static int GetArea(this Shape shape)
S>{
S>  public int a=0; 
S>  for (int i=0;i<shape.Points.Count;i++)
S>  {
S>    var pCurr = shape.Points[i];
S>    var pNext = shape.Points[(i+1) % shape.Points.Count];
S>    a += pCurr.x * pNext.y - pCurr.y * pNext.x;
S>  }
S>}
S>

Я вот думаю, окружности это несколько неправильный алгортим, если конечно шаг по X не стремится к нулю. Или Окружность и овал это не фигуры?

Здравствуйте, Serginio1, Вы писали:
S>>Я сразу писал, что в большинстве случаев достаточно иметь один класс Shape. А вся поддержка "фигур из трёх сторон" сводится к Shape CreateTriange(lenA, lenB, lenC) и другим перегрузкам метода-конструктора.
S>Да нет вроде не я являюсь автором этих фигур. Их задолго до меня изобрели.
Люди за тысячелетия наизобретали очень много всего. Это не значит, что в каждую программу нужно тащить всё это наследие.
Вот, например, зачем-то Мандельброт изобрели множество Мандельброта. В вашей программе раскроя оно представлено в виде класса? Нет? И правильно: нафиг там фракталы не нужны. Как и многое другое.

S>В большинстве случаев достаточно и фигуры ввиде массива точек, и вида соединения между точек прямолинейное или криволинейное.
Вы практически цитируете меня.

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

S>Я вот думаю, окружности это несколько неправильный алгортим, если конечно шаг по X не стремится к нулю. Или Окружность и овал это не фигуры?
В данном примере — да, не фигуры. Фигура здесь, в целях упрощения, сведена к многоугольнику.
Но вам уже минимум шесть раз в этом топике написали: для криволинейного полигона ничего в целом не меняется. Есть алгоритм расчёта площади для произвольной такой фигуры. Он уже покрывает окружности и овалы как частные случаи. Поэтому необходимости в специализированных алгоритмах я тут не вижу, тем более что для иммутабельной фигуры площадь считается не чаще раза в жизни.

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

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

S>>Алгоритм может работать с набором примитивных фигур. Например можно собирать прямоугольники из треугольников, прямоугольников, овалов, вогнутых фигур.А затем работать с прямоугольниками.
S>Эти утверждения не имеют никакого отношения к наследованию.

S>>Любая частная фигура по свой сути это фигура. Или это не так?
S>Для алгоритма размещения — нет. Для него есть только, например, прямоугольники.
S>Надо понимать, что никакой "сути" нету. Есть только код.

Почему? Прямоугольники проще располагать паралельно стороне листа и соответственно у неё будет всего две степени свободы. Для окружности и квадрата только одна.
У прямоугольника будет 4. При алгоритмах работы с разными фигурами тебе так или иначе нужен будет контракт. А вот резать ты будешь по массиву точек.
Можно делать наследование, можно агрегат с контрактом или приведение к типу. Каждый выбирает то что ему удобней.

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


S>>В большинстве случаев достаточно и фигуры ввиде массива точек, и вида соединения между точек прямолинейное или криволинейное.
S>Вы практически цитируете меня.
И не только тебя, кому проще работать с многоугольниками, чем с реальными фигурами.
Мне тоже обращаться на ВЫ? Чем я тебя обидел?

Здравствуйте, Serginio1, Вы писали:
S>А вот когда у тебя алгоритм будет работать с несколькими примитивами, тебе уже нужно работать по единому интерфейсу
Какой алгоритм будет работать с несколькими примитивами? Алгоритм размещения прямоугольников работает с прямоугольниками. Алгоритм размещения кругов — с кругами.

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

S> Нет оригинальная фигура если ты её не впишешь в прямоугольник для оптимального расположения нужно выбрать положение от крайних фигур.
S>Для треугольника это уже 4 степени свободы.
Понятие "вписывание в прямоугольник" — виртуальность. Оно существует только в рамках некоторой гипотезы размещения.
Степени свободы никуда не деваются — ведь треугольник вписать в прямоугольник тоже можно несколькими способами.

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

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

S>>Я вот думаю, окружности это несколько неправильный алгортим, если конечно шаг по X не стремится к нулю. Или Окружность и овал это не фигуры?
S>В данном примере — да, не фигуры. Фигура здесь, в целях упрощения, сведена к многоугольнику.
S>Но вам уже минимум шесть раз в этом топике написали: для криволинейного полигона ничего в целом не меняется. Есть алгоритм расчёта площади для произвольной такой фигуры. Он уже покрывает окружности и овалы как частные случаи. Поэтому необходимости в специализированных алгоритмах я тут не вижу, тем более что для иммутабельной фигуры площадь считается не чаще раза в жизни.
Только вот если я работаю с овалами и окружностями, почему я должен брать полигон? который я могу попросту вычислить, и который будет использоваться например для резки этих фигур?

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

S>Здравствуйте, Serginio1, Вы писали:
S>>А вот когда у тебя алгоритм будет работать с несколькими примитивами, тебе уже нужно работать по единому интерфейсу
S>Какой алгоритм будет работать с несколькими примитивами? Алгоритм размещения прямоугольников работает с прямоугольниками. Алгоритм размещения кругов — с кругами.
Почему? Реальные алгоритмы раскроя кожанной одежды, где нет привязки к структуре, реально работают с разными фигурами. Просто для упрощения алгоритма, можно подобрать описанную примитивную фигуру.

S>Совершенно непонятно, при чём тут работа по единому интерфейсу. Нет никакого единого интерфейса у прямоугольников и кругов, которым бы мог воспользоваться алгоритм размещения.
Почему. Есть повороты, пересечение, сдвиги итд

S>> Нет оригинальная фигура если ты её не впишешь в прямоугольник для оптимального расположения нужно выбрать положение от крайних фигур.
S>>Для треугольника это уже 4 степени свободы.
S>Понятие "вписывание в прямоугольник" — виртуальность. Оно существует только в рамках некоторой гипотезы размещения.
S>Степени свободы никуда не деваются — ведь треугольник вписать в прямоугольник тоже можно несколькими способами.
Интересно это скольким? По максимальной стороне и высоте?
Здесь речь не об этом, а о том что если мы работаем с несколькими фигурами мы можем учитывать особенности этих фигур, для оптимизации алгоритмов. Для этого нужно сделать контракт единый для всех фигур.
А вот резать мы их будем по единому алгоритму.

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

A>>

A>>var r = new Rectangle(2, 3)
A>>Square s = r;
A>>...
A>>s.A * s.A == s.GetArea() // oh my, my school teacher lies to me!
A>>

S>При чём тут ваш учитель? В контракт на GetArea() не входит проверяемый вами предикат.
S>Если вы хотите описать такую иерархию, в которой это является частью контракта, то вам придётся сделать GetArea() невиртуальным.
S>Это, конечно же, приведёт к другим проблемам. Но главное видно уже на этом примере: контракты формулируются не сами по себе, а в ответ на некоторые требования.

нет.
в первую очередь контракты и требования не должны быть контр-интуитивными.
если есть объект Квадрат, то его площадь должна быть равна квадрату стороны. Иначе он не может называться "Квадрат".

если есть метод add(a, b), то в его реализацией не может быть { return a — b };

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

S>Здравствуйте, Serginio1, Вы писали:
S>>А вот когда у тебя алгоритм будет работать с несколькими примитивами, тебе уже нужно работать по единому интерфейсу
S>Какой алгоритм будет работать с несколькими примитивами? Алгоритм размещения прямоугольников работает с прямоугольниками. Алгоритм размещения кругов — с кругами.

Вот кстати пример более сложного кроя, при том, что края материала криволинейной формы http://lemarse.spb.ru/products/cut_leather/

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

S> То есть все частные формы фигур не нужны?
Что значит "фигуры"? Как типы не нужны. Во всяком случае в задаче оптимизации раскроя.
Они могут быть использованы в виде упрощённых рамок для деталей. Но при этом им достаточно быть просто массивами дуг/отрезков, как и остальным фигурам.

S> Координаты я всегда могу вычислить по начальной координате и сторонам. А вот степеней свободы для размещения у прямоугольника всего 2.

Так это и надо хранить! Именно это -- способы размещения. Способ размещения -- это диапазон углов поворота + надо ли отражать (если раскрой такое допускает). Простая структура из двух чисел и одного була. Массив таких структур и ФСЁ!!!

S> Исходя из тех же степеней свободы.
Каких степеней свободы? У тебя же все фигуры жёсткие, их нельзя деформировать. Так что степень свободы ровно одна -- поворот! Ну может ещё отражать можно, от задачи зависит.

S>Для треугольника будет 4 степени свободы.
Что ты называешь "степень свободы"?..

S> Я не вижу разницы между агрегацией и наследованием. Объект может вести себя и как любой агрегат в его составе. Мало того в COM вовсю используется

То есть ты таки правда в ООП совсем не разобрался. Бывает. Говорят есть книжки всякие там про принцип подстановки Лисовски и т. п., говорят некоторым они помогают

S>В приведенном примере использование директивы implements говорит о том, что методы, реализующие интерфейс IFoo, следует искать в свойстве Foo.

А при чём тут вообще наследование?

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

S>А вот когда у тебя алгоритм будет работать с несколькими примитивами, тебе уже нужно работать по единому интерфейсу

А зачем ему рабоать с несколькими примитивами?

S> Нет оригинальная фигура если ты её не впишешь в прямоугольник для оптимального расположения нужно выбрать положение от крайних фигур.
Почему и кому это "нужно"?
Смотри, если я решаю, что эту фигуру надо вписать в прямоугольник и дальше прямо вот как прямоугольник и размещать, то это, на самом деле означает, что я всего-то фиксирую углы поворота этой фигуры, котрые стоит попробовать. Конкретно 90 о 0 градусов. И ВСЁ, боьше это ничего не значит.

S>Для треугольника это уже 4 степени свободы.
IMHO, если отражать нельзя, то у треугольника РОВНО одна степень свободы, так же, как и у любой другой фигуры -- это то, на сколько градусов его можно повернуть относительно первоначального положения