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

S>А теперь периметр посчитай.
Ну будет сумма длин сторон. Хоть так, хоть сяк...
Тоже не понятно чем специальная формула для треугольника будет лучше...

S> Особенно это правильно делать для окружностей где достаточно хранить радиус. Для прямоугольника достаточно хранить две стороны.

В смысле "храниить"? У тебя исходные данные -- это координаты вершин или что?
Про окружность тоже не понятно. Если отрезки криволинейные, то формулы площадей трапеций и длин отрезков чуть сложнее, но структура вычислений та же. Так что всё равно общий алгоритм будет и быстрым и точным. Не понятно зачем делать специальный. Но даже если и делать не понятно зачем полиморфизм.

S> Для треуголька, прямоугольника проще оперировать сторонами.
Что значит в данном случае "проще"? Исходно же у нас не стороны, а координаты. И для совмещения с другими деталями нам нужны не стороны, а координаты. Ты стебёшься что ли?

S> И поворачивать их на 10% в раскрое не имеет смысла.

Почему не имеет? Откуда следует? Кроме того, даже еслими следует, это можно просто понять прямо там, где мы решаем, что эта фигура похожа на треугольник, например

S> Ладно. Извини. Я на этом прекращу. А то это бесконечный разговор.
То есть таки стебёшься...

В принципе уже там, где ты всерьёз стал доказывать, что множественное наследование и агрегация это одно и то же, можно было наверное однозначно понять, что это всё такой тонкий первоапрельский троллинг

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

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

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

У портных есть тонкость, обычно ориентация всех деталей относительно утка и основы строго задана...

S>Поэтому мне понятна проблема с раскроем. Это более сложная задача, чем задача о рюкзаке.
И что с того? Я вот, в основном, наработе укладываю такие рбкзаки, но ен в одно- или дву-мерном пространстве (задача раскроя), а в пространстве с сотнями измерений.
Ты говоришь вообще не о том. Ты всё время упираешь на то, что что-то там легче повернуть, пересчитать, упростить какую-то формулу и т. д.
Но это всё оптимизация раз в 10, и то если повезёт. То, что ты пока что предлагал, IMHO, вообще писсимизация, а не оптимизация.

А в таких задачах нужно оптимизировать на несколько порядков, хороше, если не на много порядков, а только на три-четыре.
Скажем в предыдущей задаче мне удалось оптимизировать перебор примерно в 100 000 раз...
Понимаешь, надо копать что и как там в этом пространстве состояний этого укладчика можно выциганить, а не какой-то хренью с ООП рюшечками страдать

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

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

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

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

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

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

И что с того? Вертеть фигуры НЕ СЛОЖНО.
Правда конкретно у портных вертеть фигуры НЕЛЬЗЯ.

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

S>Аргументы типа "из двух прямоугольных треугольников легко сделать прямоугольник" прошу не приводить, т.к. они оскорбляют здравый смысл. Ведь такое утверждение никакого отношения к вопросам наследования не имеет — никто (я надеюсь) не будет всеръёз рассматривать это как повод для множественного наследования прямоугольника от двух треугольников и прочего шизофренического бреда.

Гыгы) А забавная идейка. Только надо взять язык с динамическим множественным наследованием (вроде Self был такой) и тогда можно такую наркоманию навернуть...

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

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

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

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


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

---

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

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

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

_>Гыгы) А забавная идейка. Только надо взять язык с динамическим множественным наследованием (вроде Self был такой) и тогда можно такую наркоманию навернуть...

Не понятно, что делать, если метод есть в обеих базах. Что наследует MDT при этом? Вызов обоих методов? А что получим как результат?

А так можно не вспоминать мучительно Self, а просто на С++ всё налабать. Никто же не мешает реализовать на С++ другую модель объектов?

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

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

S>

S>public class Rectangle: Square
S>{
S>  public Rectangle(int a, int b): base(a)
S>  {
S>    _b = b;
S>  }
S>  private int _b;
S>  public int B { get { return _b; }} 
S>  public override int GetArea(): { return A * B }
S>  public override int GetPerimeter(): {return 2*A + 2*B;}
S>}
S>

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

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

S>Вопрос уместности ООП в системах документооборота остаётся открытым. ООП привносит много проблем. В частности, в ООП тип (класс) объекта предполагается неизменным, а в документообороте совершенно нормальной является смена типа. Точнее, на разных этапах жизенного цикла документ реализует существенно различные контракты, так что делать их частью типа — бессмысленно.

выбор абстракций зависит от решаемой задачи

S>В реальных решениях все эти иерархии фигур, столь популярные в учебниках, отсутствуют за ненадобностью. В реальной графической программе у вас скорее всего будет что-то вроде одного класса Shape, который состоит из набора прямых, дуг, и кривых Безье. А все "фигуры" будут описываться всего лишь конструкторами.

ни разу не видел ООП в "графической программе", только в поделках любителей, и то это вряд ли ООП.
всё что лежит поверх графики или рядом с графикой ещё похоже на ООП, а сама графика чаще всего копипаста из Open source.
можно ли directX и openGL считать ООП или графикой остаётся открытым.

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

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

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

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

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

man Generation Gap pattern.
Я его, правда не использовал, т.к. в генереном коде обычно ничего не правлю

а вот что по этому поводу думает почта США:

if Envelope is NOT Rectangular or Square

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

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

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

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

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

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

Здравствуйте, DarkGray, Вы писали:
DG>В качестве примера, можно взять gdocs — у документа есть метод Download as. Само же поведение вызываемое этим методом находится не в документе, документ является лишь проксей.
Как и денормализация в БД, добавление таких utility-методов должно делаться уже после того, как "нормализованный" дизайн получен и отлажен. И только там, где это действительно необходимо.
Понятно, что удобнее иметь метод TextReader.Open(string filename), чем писать громоздкие перфекционистские new TextReader(FileStream.Open(filename));

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


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>

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

Большинство спорщиков на эту тему почему-то напрочь игнорируют вопрос требований, и бросаются критиковать решения, произвольным образом выбирая критерии.

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



S>> Еще раз треугольник наследуется не от квадрата, а от абстрактной фигуры с массивом точек и абстрактными методами периметр и площадь. Она будет родителем для любой фигуры в том числе и множества частных случаев этих фигур.
S>Ещё раз: зачем наследовать треугольник? Все нужные от него методы уже реализованы для "фигуры из N точек". Вы же не думаете, что периметр трапеции вычисляется как-то иначе, чем периметр прямоугольника?
Зачем вообще вводить лишнюю сущность как фигура из трех сторон? Зачем вводить замечательные пределы итд?

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

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

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



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

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

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

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

Всё. Что ещё вы хотите тут написать? Я мог бы для пущей понятности переписать это на linq, или для пущего быстродействия — на ассемблере c SSE, или, наоборот, скормить это в графическую карточку.

Но смысла садиться специализировать этот код для каких-то отдельных видов фигур я не вижу.


S> Я тебе дал пример где это может использоваться. Кстати а чем агрегат лучше наследования? По сути в C++ агрегирование и множественное наследование мало чем отличаются.
Агрегат лучше возможностями повторного использования.

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

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

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

S>>А теперь периметр посчитай.
E>Ну будет сумма длин сторон. Хоть так, хоть сяк...
E>Тоже не понятно чем специальная формула для треугольника будет лучше...
То есть все частные формы фигур не нужны?

S>> Особенно это правильно делать для окружностей где достаточно хранить радиус. Для прямоугольника достаточно хранить две стороны.

E>В смысле "храниить"? У тебя исходные данные -- это координаты вершин или что?
E>Про окружность тоже не понятно. Если отрезки криволинейные, то формулы площадей трапеций и длин отрезков чуть сложнее, но структура вычислений та же. Так что всё равно общий алгоритм будет и быстрым и точным. Не понятно зачем делать специальный. Но даже если и делать не понятно зачем полиморфизм.

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

S>> Для треуголька, прямоугольника проще оперировать сторонами.
E>Что значит в данном случае "проще"? Исходно же у нас не стороны, а координаты. И для совмещения с другими деталями нам нужны не стороны, а координаты. Ты стебёшься что ли?
Исходя из тех же степеней свободы.

S>> И поворачивать их на 10% в раскрое не имеет смысла.

E>Почему не имеет? Откуда следует? Кроме того, даже еслими следует, это можно просто понять прямо там, где мы решаем, что эта фигура похожа на треугольник, например
Для треугольника будет 4 степени свободы.

S>> Ладно. Извини. Я на этом прекращу. А то это бесконечный разговор.
E>То есть таки стебёшься...

E>В принципе уже там, где ты всерьёз стал доказывать, что множественное наследование и агрегация это одно и то же, можно было наверное однозначно понять, что это всё такой тонкий первоапрельский троллинг
Да нет. Опять же привожу пример в 1С. Где нет наследоваия, но где во всю используется утиная типизация. При этом в голове нужно держать какие контракты нужно наследовать, и если контракт не совпадает по наименованию (поддержка чужих конфигураций ), для каждого типа делать проверку.
Я не вижу разницы между агрегацией и наследованием. Объект может вести себя и как любой агрегат в его составе. Мало того в COM вовсю используется

Директива implements впервые была введена в Delphi 4. Она позволяет делегировать реализацию методов интерфейса другим классам или интерфейсам. Директива implements всегда указывается как последняя директива в объявлении свойства класса или интерфейса.

type

TSomeClass — class(TinterfacedObject, IFoo) function GetFoo: TFoo;

property Foo: TFoo read GetFoo implements IFoo; end;

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

Тип свойства должен быть классом, содержащим методы IFoo, интерфейс IFoo или его потомков. В директиве implements можно использовать не один, а целый список интерфейсов (элементы списка должны отделяться запятыми). В таком случае класс, используемый для представления свойства, должен содержать методы, реализующие все приведенные в списке интерфейсы.

Директива implements позволяет выполнять бесконфликтную агрегацию. Агрегация — это концепция СОМ, отвечающая за комбинацию нескольких классов для выполнения одной задачи. Другое немаловажное преимущество применения директивы

Можно через рефакторинг нагенерить и методы объекта интерыейсов через доступ к методам агрегатам, что бы исключить доступ через точку.

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