Re[31]: Наследование квадратов и прямоугольников - Философия программирования

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

E>>Ты перебираешь маленькие углы поворотов? Зачем? Можно же сразу вычислить на какой угол максимально можно повернуть фигуру в эту или в другую сторону?

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

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

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

S>Поэтому мне понятна проблема с раскроем. Это более сложная задача, чем задача о рюкзаке.
И что с того? Я вот, в основном, наработе укладываю такие рбкзаки, но ен в одно- или дву-мерном пространстве (задача раскроя), а в пространстве с сотнями измерений.

Ты говоришь вообще не о том. Ты всё время упираешь на то, что что-то там легче повернуть, пересчитать, упростить какую-то формулу и т. д.
Но это всё оптимизация раз в 10, и то если повезёт. То, что ты пока что предлагал, IMHO, вообще писсимизация, а не оптимизация.

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

Понимаешь, надо копать что и как там в этом пространстве состояний этого укладчика можно выциганить, а не какой-то хренью с ООП рюшечками страдать

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

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

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

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

I>Про то и речь, что квадрат здесь ровно один, задаётся ровно двумя точками. Третий параметр обязателен только для прямоугольника и один единственный прямоугольник невозможно задать только этими двумя точками, нужен и третий параметр который ты сам же и ввёл.

И? Чем нам не подходит класс Rectangle для описания квадратов? Создание отдельного класса квадратов в таком случае имеет смысл только в очень специфической ситуации: если мы имеем дело с миллиардами квадратов, хранящихся в оперативной памяти. Тогда создание отдельного класса позволит (причём если храним их не смешивая с прямоугольниками, иначе на полиморфизм пойдёт та же самая память) уменьшить расход памяти на 20%. При этом увеличив сложность кода, так что это имеет смысл только при обнаружение узкого места по памяти, а иначе является классической преждевременной оптимизацией. Для всех остальных случаев использование класса Rectangle для описания квадрата будет вполне адекватным.

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

Хыхы, это не следствие равенства сторон. А у прямоугольника они не под прямым что ли пересекаются? ))) Равенство сторон приводит только к общей точке пересечения.

I>Ну если ты все еще сомневаешься, то покажи окружность, вписаную в прямоугольник(который квадратом не является) ну и покажи как унифицировать такой интерфейс.

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

Здравствуйте, alex_public, Вы писали:
I>>Не хочется проводить ликбез по планиметрии, но т.к. треугольник из двух сторон и диагонали опаньки! равнобедренный а у него биссектриса из угла между равными сторонами пересекает стретью торону под прямым углом.

_>А я нигде и не утверждал, что они пересекаются не под прямым углом. Я сказал лишь что это равенство сторон не является необходимым условием этого.

Имелось ввиду, что диагональ есть биссектриса.

I>>Мне просто кажется ты привык к своим задачам и ничего дальше даже не хочешь рассматривать. Я собственно не утверждаю, что класс квадрат надо вводить в любом случае. В качестве оптимизаций — запросто, существенно упрощает логику, т.е. не надо будет обкладывать логику проверками, исключениями и прочей мутью, когда большая часть вычислений завязана на свойства именно квадрата, а не прямоугольника.

_>Если у нас в задаче есть только квадраты, то естественно что никакие прямоугольники и не должны всплывать. Если же есть и то и другое, то логично использовать один класс, обобщающий их свойства. За исключением редкой ситуации, когда возникает узкое место по ресурсам.

С этого все и начиналось — "В качестве оптимизаций".

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

I>>

Нет и это очевидно любому кто учил геометрию. Эту разницу можно использовать для оптимизации.
I>>Собтсвенно после такого ляпа можно и разговор заканчивать, но я нынче добр

S>Поздравляю вас с успешным завалом выпускного экзамена по геометрии за 9й класс.
S>Вот вам картинка про биссектрисы углов в прямоугольнике — медитируйте до просветления:
S>

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

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

S>А для Окружности вообще нечего поворачивать.

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

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

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

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

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

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

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

Здравствуйте, Serginio1, Вы писали:
S>>Надо понимать, что никакой "сути" нету. Есть только код.
S> Почему?
Потому, что программисты работают с кодом, а не с сутью.

S>Прямоугольники проще располагать паралельно стороне листа и соответственно у неё будет всего две степени свободы.
"у неё" — это у кого? У стороны листа? У неё вообще степеней свободы нет.
S>Для окружности и квадрата только одна.
Вообще-то у круга (который вы почему-то упорно называете окружностью) и квадрата две степени свободы — это их координаты x и y. При условии, что мы не рассматриваем крой с квадратами под произвольными углами.
S>У прямоугольника будет 4.
У прямоугольника — две степени свободы; при этом одна из них дискретная.
S>При алгоритмах работы с разными фигурами тебе так или иначе нужен будет контракт. А вот резать ты будешь по массиву точек.
В последний раз повторюсь, а то я вижу, что с пяти раз аргументы не доходят и вы долдоните одну и ту же чушь:
Общий контракт нужен только если один и тот же алгоритм потребуется применять к разным фигурам.
У вас для размещения кругов и для размещения прямоугольников используется один и тот же алгоритм?
Далее, использовать наследование при реализации этого контракта нужно только в том случае, если есть хоть какой-то полиморфизм.
Про отсутствие полиморфизма при вычислении площади и периметра криволинейных многоугольников мы уже поговорили, пожалуйста не пишите по данному вопросу больше ничего.
Про полиморфизм среди фигур по отношению к размещению я ничего не могу сказать, пока не увижу алгоритм. Очень может оказаться, что если и существует некий общий алгоритм размещения, работающий что для прямоугольников, что для кругов, то никаких иерархий фигур в его аргументах не будет. А просто фигура будет сразу описываться параметрами её симметрии (которые задаются в конструкторе, точно так же, как и список точек для произвольного полигона), и из них алгоритм будет автоматически определять варианты размещения для перебора.ю

S>Можно делать наследование, можно агрегат с контрактом или приведение к типу. Каждый выбирает то что ему удобней.
Пока что в вашем сумбурном описании задачи не видно места ни для наследования, ни для агрегата с контрактом, ни для приведения к типу.
Это означает, что кто-то из нас катастрофически заблуждается. Надеюсь, что я — потому что свои заблуждения мне исправить гораздо легче, чем чужие.

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

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

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

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

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

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

По моему у тебя плохо с наследованием. Агрегация это тоже наследование, при этом имплементс это директива поведения объекта, где все методы берутся из агрегата.
ООП это не только полиморфизм, но и наследование своств и методов.

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

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

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

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

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

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

E>Просто специфика области. Всё удобно представлять векторами чего-то...

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

S>>Но при этом когда очевидно что любая частная фигура это наследник более общего понятия Фигура, здесь начинается флейм, а зачем и для чего.
E>IMHO, очевидно, что это не так.
E>В целом, если "фигура вообще", это таки массив сегментов (дуг там, отрезков или ещё чего), то она самодостаточна и никакие наследники ей, так же как и друнгим массивам, не нужны.

E>Просто тот, треугольник, например, который ты тулишь этой фигуре в наследники, будет содержать на борту три доп. длины стороны, в целом избыточные, и ещё, может быть, угол поворота вокруг первой вершину, тоже избыточный. Это не наследник, а просто альтернативное представление

E>Ты же не считаешь, что комплексное число в нормальной форме является предком комплексного числа в экспонециальной?

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

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

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

E>3) Ограничение гипотез по размещению детали при раскрое -- ООП для задания списка дипазонов допустимых углов поворота нужно, то есть тоже усложнение без всякой пользы.
Ну да проще крутить на все углы. При этом учитывая что это NP полная задача и нужно оптимизировать задачу, а её проще решить именно зная характер фигуры.

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

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

S>> Здесь как раз может иметь место 2 алгоритма один заложенный в фигуру, другой общий. При этом общий может быть и у любой произвольной фигуры. Это как аналог построения ДКА.

E>Если общий работает плохо, то на кой он нужен вообще? Лучше уж тогда всё прямоугольниками, например, апроксимировать и не жужжать.
E>А если хорошо, то на кой нужен второй алгоритм?

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

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

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

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

I>Конечно разные. Сможешь однозначно задать произвольный прямоугольник на плоскости с помощью всего двух точек — дам 100$

Две точки — это 4 независимых числа. И прямоугольник и квадрат заданного размера задаются на плоскости 3-я числами. Соответственно размер у прямоугольника — это ещё 2 независимых числа, а у квадрата одно независимое числе (т.е. получаем те же самые 4). Таким образом получаем всё тоже самое, но с сохранением единого интерфейса. Чудес в математики не бывает. )))

I>Как должно, никому не интересно. Интересно выжать максимум оптимизаций из этой разницы. Одну из оптимизаций я уже подсказал.

Ууу, оптимизация... Если уж дело доходит до неё (и она не преждевременная), то обычно это происходит в стиле всяческих костылей, а не как другая красивая архитектура (а тут мы вроде как обсуждаем именно это).

Здравствуйте, DarkGray, Вы писали:
DG>Проблем становится меньше, но они все равно остаются. Если, конечно, речь идет о сохранении контракта родителя, а не просто о наследовании реализации.
Вопрос — в том, что считать контрактом. Вот, к примеру, на некотором уровне абстракции IEnumerable<T> и Nullable<T> реализуют один и тот же "контракт". Что, естественно, никак не выражено, да и невыразимо в системе типов .Net.

DG>У наследника для некоторых методов может меняться тип результата, что разрушает контракт родителя.
Это если вы так обозначили тип результата в контракте.
DG>Для пары квадрат/прямоугольник такого метода сходу не скажу, а для пары эллипс/круг он известен.

DG>Метод "Получить_Оси_Симметрии" для эллипса возвращает тип Конечное_множество_известного_заранее_размера<2, Ось_Симметрии>, а для круга возвращает тип Неисчислимое_множество<Ось_Симметрии>.
Ну, мы же понимаем, что этот метод должен вернуть вам неисчислимое множество сразу же у эллипса, которому не повезло иметь совпадающие фокусы. Даже без введения типа "круг". Поэтому метод обязан с самого начала возвращать множество, а уж какова будет его мощность — сие зависит от параметров фигуры.

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

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

А когда ты этот код перегенерируешь ты точно вспомнишь, где ты раньше правил?

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

... << RSDN@Home 1.2.0 alpha 5 rev. 62>>

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

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

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

А когда ты этот код перегенерируешь ты точно вспомнишь, где ты раньше правил?
А вот я сравню новый код со старым.

и изменю (добавлю) только тот код который требуется.
S>>Ну и опять же я даю это для себя любимого. А кто не хочет брать эту обработку, тот может пользоваться другими инструментами. Нет жесткой зависимости.
WH>Ну да. Любой код можно выбросить... Вообще не понял к чему ты.
Ну я к тому, что ваш спор сводится в общем к одному. DSL это хорошо, до тех пор пока его не приходится поддерживать не авторами DSL.
И здесь каждый манагер для себя выбирает какой код проще поддерживать. Ведь как правильно было замечено на создание уходит меньше времени, чем на его поддержку.
Если общие DSL изучают все, то для доморощенного нужно тратить время на обучение, вникание и не всем это посильно. Самому (и не только мне одному) кстати проще переписать, чем поддерживать чей то невнятный код.
Ну а любой код не выбрасывается, так как из старого можно выборочно построить новый. Ну и тренировка ума.

Здравствуйте, Serginio1, Вы писали:
S> Ну да. Вот например тебе в наследство достался член. Но ты то ли из-за каких то проблем с размером решил этот член отрезать и вместо него пришить новый.
S>Ну во первых это опасно для здоровья, а во вторых как многими доказано размер не имеет значения. Зачем плодить лишние сущности?
~~Идиотские~~ некорректные аналогии обсуждать не будем.

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

S> Ну не везде и не всегда. Я вот сейчас работаю на мебельной фабрике. Там есть программы для оптимального расположения фигур для резки, с минимальными количествами отходов.
S>Но в основном эти фигуры являются прямоугольниками и нет большого смысла городить огород со сложными фигурами. В любом случае их проще вписать в прямоугольники для упрощения алгоритма (криволинейный крой).
Ну вот видите, в вашем алгоритме нет никаких иерархий фигур. Фигура определяется реальной формой (поликривая) и её bounding rectangle.
S>И квадрат в этом случае ничем от прямоугольника не отличается.
Как, впрочем, и от круга, эллипса, звезды Соломона и профиля Руссиновича.
S>Хотя есть и программы которые работают со сложными фигурами, но вот алгоритм там совсем другой, более сложный и затратный. Но вот им в реальных условиях не пользуются.
И даже в нём нет никаких иерархий фигур.
S> Если для тебя наследование реализации — один из худших видов наследования, то для меня все наоборот. Меня интересует минимум написания кода при введении нового элемента в иерархию.
Совершенно верно. Именно поэтому наследование реализации — зло: при нём введение нового элемента в иерархию может затронуть неограниченный объём кода. Ведь элемент может появиться не только в листе. Любое изменение в базовом классе начинает распространяться на всех наследников как степной пожар.

S>Кстати в Delphi есть такой подход как виртуальные методы класса.
Я в курсе. И связано это с понятием "ссылки на класс", которого нет в других языках программирования. Фактически, в Delphi есть две параллельных иерархии наследования — классов и метаклассов. В дотнете Хейльсберг решил этим не задуряться.

S> Ну и в чем различие между Интерфейсом и наследованием VMT если все методы перекрываются? Только в организации доступа к этим таблицам.
Вы слишком много внимания уделяете несущественным деталям, вроде VMT и организации доступа. Это вам мешает.
Наследование реализации — это в том числе и наследование состояния, чего нет в случае реализации интерфейса.

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

_>И? Чем нам не подходит класс Rectangle для описания квадратов? Создание отдельного класса квадратов в таком случае имеет смысл только в очень специфической ситуации:

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

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

_>Хыхы, это не следствие равенства сторон.

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

> А у прямоугольника они не под прямым что ли пересекаются? ))) Равенство сторон приводит только к общей точке пересечения.

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

I>>Ну если ты все еще сомневаешься, то покажи окружность, вписаную в прямоугольник(который квадратом не является) ну и покажи как унифицировать такой интерфейс.

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

С точки зрения разработки это можно использовать для вычислений. Кстати, ты в курсе, что у квадрата еще две дополнительные оси симметрии и это тоже можно использовать для оптимизации ? Привет векторная алгебра !

Похоже, ты отрицаешь, что свойства квадрата и прямоугольника отличаются

Мне просто кажется ты привык к своим задачам и ничего дальше даже не хочешь рассматривать. Я собственно не утверждаю, что класс квадрат надо вводить в любом случае. В качестве оптимизаций — запросто, существенно упрощает логику, т.е. не надо будет обкладывать логику проверками, исключениями и прочей мутью, когда большая часть вычислений завязана на свойства именно квадрата, а не прямоугольника.

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

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

S>> Почему? Треугольник как раз и является наследником фигуры с массивом точек. Разве не так?
S>Ещё раз намекну: это зависит от того, какой контракт вы хотите получить от фигуры и от треугольника.
S>Если в контракт фигуры входит (естественная для мутабельных объектов) операция "void insertPoint(Point newPoint, int position)", то треугольник отнаследовать от этой фигуры никак не получится.
S>Если фигура — immutable, то в её контракт такая операция входить не может.
S>Зато может входить операция типа int getArea(). Но её не имеет смысла делать полиморфной, поэтому наследование треугольника вовсе не нужно. Достаточно иметь метод типа
S>

S>Shape CreateTriangle(Point a, Point b, Point c)
S>

;
S>Наследование нужно там, где нужен полиморфизм и возможность подстановки. В геометрии таких задач нет.

Почему?

Вот Например
class Фигура()
Point [] массивТочек;
public Фигура(int[] массивТочек)
public void Начертить();

end;

class треугольник:Фигура
public треугольник(Point a, Point b, Point c)
{
массивТочек=new Point[]{a,b,c}

}
void ПовернутьТреугольникНа90Градусов()
end

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

S>>>Вы не ответили на вопрос.
S>> Не хватает трех, а эти три отличаются от дефолтных.
S>Вы по-прежнему не ответили на вопрос.
А какой ответ ты хочешь услышать? Для функциональности хэлпера я должен придоставить интерфейс со 100 свойствами.
У меня есть 2 подхода либо реализовывать этот интерфейс внутри класса, либо создать класс поддерживающий этот интерфейс и заполнить только часть его полей (значительно меньшую) оставив остальные по умолчанию.

S>>>И какое отношение к преобразованию int в double имеет IEnumerator IEnumerable.GetEnumerator()?
S>> А тем что всето приведения к интерфейсу, можно этот интерфейс запросить через GetIntefaсe<T>()
S>Ну это совсем другое. Посмотрите внутрь GetEnumerator для интереса.
Ну и например Энумераторы на основе поля в составе класса или куча yield, где генерятся классы обертки. Все то о чем я тебе и говорю.
Кстати а с чего это ты на Вы перешел. Может и мне на Вы при общении с тобой перейти.

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

S>> За подход без наследования.
S>Нет, я за подход без лишнего наследования.

Я тоже. Но где я говорил, что ООП это панацея. Я говорю лишь о том, что наследование явно существует. Просто не везде она многоуровневая. В большинстве двухуровневая.

S>> Но она существует. Если у тебя нет то я только сочувствую тебе.
S>Жду убедительного примера.
Да я уже тебе кучу примеров приводил. И с документами со справочниками и с автоматами итд.

S>> Ну ты чего то автоматы пропустил. Я за автоматы на основе иерархии, ты за автоматы на уровне ветвлений.
S>Я не понимаю, о каких автоматах вы говорите, и не понимаю, зачем вы приписываете мне мнения, которых я не разделяю.
Детеринированные конечные автоматы ДКА.

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

S>Вот Например
S>class Фигура()
S>Point [] массивТочек;
S>public Фигура(int[] массивТочек)
S>public void Начертить();

S>end;

S>class треугольник:Фигура
S>public треугольник(Point a, Point b, Point c)
S>{
S> массивТочек=new Point[]{a,b,c}

S>}
S>void ПовернутьТреугольникНа90Градусов()
S>end

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

Интересно, а из std::vector ты тоже выводишь наследникв "вектор из трёх элементов", "вектор из четырёх элементов" и т. д?..

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

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

S>> А зачем тратить лишнее время. Сколько точек нужно для расчета периметра илм площади для окружности?

E>А ты окружность наследуешь из полигона с каким числом вершин, кстати?..

А ничего смешного то здесь нет. В криврлинейке там можно задавать и полигон, и сплайны итд.

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

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

1) При чём тут "докапаешься"? Ты просто очень непонятно пишешь. Правда не понятно, что ты имеешь в виду.
2) А почему этот подход является хорошим? Эти "описанные" прямоугольники труно искать, трудно проверять их на пересечение, и они нужны только для отсечения окончательной проверки в конце концов.

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

У тебя сколько фигур в типичном раскрое? штуки? Десятки? Сотни?..

S> Еще раз я уже писал тебе про NP полную задачу. Предлагаю тебе двинуть в эту область одна из таких программ K3.

Спасибо, но я пока двигаю свою. Пока что наша группа лидирует...

Кстати, думаешь задача потимизации С++ не NP-полна что ли? Тем не менее обогнать оптимизатор С++ трудно, а ту программу в которой якобы есть все эти иерархии, как ты утверждаешь, таки можно, опять же, как ты утверждаешь...

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

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

S>> Я тебе привел пример для чего нужны площадь и периметр.
E>Да площадь и периметр могут и просто так заинтересовать. Не важно. Важно то, что их вычисление во время поиска оптимального раскроя не требуется...

E>Ну и для вычисления площади и периметра фигуры не нужно занть её форму, достаточно представления как массива ограничиваюих отрезков или дуг...

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

S>>Нужен периметр.
E>И что, это какая-то сложная задача, что ли? Зачем периметр треугольника или даже окружности, считать как-то иначе, чем периметр n-угольника?
У тебя ничего нет сложного. Для вычисления площади окружности достаточно всего одного радиуса, для вычисления площади квадрата достаточно одной стороны.

E>>>Не в разы разница -- это структура перебора вариантов. Её-то и надо оптимизировать, а не фигню.

S>> Ну так этих вариантов тем больше, чем более сложные фигуры.

E>Именно поэтому надо задавать целенаправленность и отсечения в перебор вариантов, а не заниматься ерёндой с ООп-представлением фигур

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

E>IMHO, Это говорит, что твоя прекрасная ООП-программа просто не работает. Долго и вычурно вычисляет не то...

Это не моя. Это K3.

E>Сравни с оптимизирующим компилятором С++, например. За ним вручную не особо пооптимизируешь, в отличии от. Только не надо говорить, что задача кроя проще, чем задача оптимизации С++

Еще раз напомню класс задач NP полный. Как только ты прикинешь количество вариантов расположения 50 разных деталей на листе то все станет предельно ясно.

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

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

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

E>Зачем всё это усложнение?
E>У тебя есть две сущности.
E>1) фигура
E>2) Вариант её размещения в раскрое.
E>Почему ты хочешь связать эти сущности отношением наследования?

E>Зачем? В какой момент и для какой операци тебе хочется работать с вариантом размещения, как с фигурой?
Я уже ничего не хочу. Еще раз. Любую фигуру я могу представить как массив точек и характер соединения точек.
Для алгоритмов раскроя мне проще оперировать простыми фигурами котрыми я могу описать эту фигуру. Манипулировать этими фигурами я буду по единому интерфейсу, а пилить я буду по массиву точек.

E>>>Примеры многих базовых алгоритмов таки будут?
S>>синус косинус итд. Я же написал тригонометрия. Числовые методы интегрирования итд.

E>Не понимаю, что такое синус окружности, например? Или n-угольника?

Замечательный предел помнишь? И как расчитать площадь n угольника?

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

S> Я уже ничего не хочу. Еще раз. Любую фигуру я могу представить как массив точек и характер соединения точек.
Да, и это верно.

S>Для алгоритмов раскроя мне проще оперировать простыми фигурами котрыми я могу описать эту фигуру. Манипулировать этими фигурами я буду по единому интерфейсу, а пилить я буду по массиву точек.
Это тоже, скорее всего верно. Типа по каждой фигуре мы строим некий объект, который умеет генерироватьили содержит, осмысленные варианты размещения, умеет их как-то оптимизировать итерировать ипроверять, что нет пересечений.

Зачем с раскроем для станка и с этим объектом, условно "гипотезой о размещении" уметь работать как с одним и тем же типом?

S>>>синус косинус итд. Я же написал тригонометрия. Числовые методы интегрирования итд.
E>>Не понимаю, что такое синус окружности, например? Или n-угольника?

S>Замечательный предел помнишь? И как расчитать площадь n угольника?

Если у теюя n-угольник задан КООРДИНАТАМИ своих вершин (у тебя же так задан, я надеюсь?), то что бы рассчитать его площадь надо просто просумировать по кругу (x[i]-x[i+1])*(y[i] + y[i+1]) и разделить результат на 2. (Тут предполагается, что после последнего индекса +1 переходит снова к первому)
Правда площадь получится со знаком, который зависит в каком направлении описывался n-угольник. Но знак легко отбросить.
Этот метод быстрый, так как содержит всего-то 3N сложений и N умножений (ну и в конце надо ещё на 2 поделить, правда). При этом, если исходные данные целые, то и все промежуточные ТОЖЕ, так что он ещё всё вычисляет ТОЧНО, то есть вообще без погрешностей.

если же считать площадь по 3-ка по формуле Герона, а не по этой общей, то надо сначала вычислить три длины стороны (это уже куча умножений, сложений и три корня квадратных в конце), и эти все вычисления уже в плавучке и с погрешностями.
Потом эти длины сторон надо будет складывать и перемножать, а из результата извлекать корень. Можно пояснить на кой это вс делать?

Это типа первоапрельская шутка такая что ли?..

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

S> Обогнать по времени компиляции легко.
Обычно надо не по времени компиляции, а по хорошести её результатов...

S>Моих иерархий нигде может и не быть. Но они возможны и не значит, что они будут менее эффективны даже в первом приближении.

Ну ты это можешь как-то обосновать-то? Пока я так и не поянл, как всё это твоё ООП помогает как-то оптимизировать перебор?

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

E>>Конкретка-то будет?
S>Еще раз повторю, для расположения фигур на листе.
Это цель, а не алгоритм!

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

S> Занматься размещением простых фигур проще, чем крутить вертеть по маленькому углу многоугольные фигуры.

Ты перебираешь маленькие углы поворотов? Зачем? Можно же сразу вычислить на какой угол максимально можно повернуть фигуру в эту или в другую сторону?

S> Это от алгоритмов зависит. А чем проблемы раскроя не топ задача?
Ну пиши алгоритмы, решающие эту задачу. Просто нужны примеры КОНКРЕТНЫХ алгоритмов решающих КОНКРЕТНЫЕ задачи. Иначе разговор беспредметен.

S> Почему прямоугольник или прямоугольный треугольник не является наследником фигуры с массивом точек?
Это неправильный вопрос. Правильный вопрос "зачем им быть такими наследниками"?

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

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

S>> Обогнать по времени компиляции легко.
E>Обычно надо не по времени компиляции, а по хорошести её результатов...

S>>Моих иерархий нигде может и не быть. Но они возможны и не значит, что они будут менее эффективны даже в первом приближении.

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

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

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

E>>>Конкретка-то будет?
S>>Еще раз повторю, для расположения фигур на листе.
E>Это цель, а не алгоритм!

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

Про сплайны я уже упоминал.

S>> Занматься размещением простых фигур проще, чем крутить вертеть по маленькому углу многоугольные фигуры.

E>Ты перебираешь маленькие углы поворотов? Зачем? Можно же сразу вычислить на какой угол максимально можно повернуть фигуру в эту или в другую сторону?

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

S>> Это от алгоритмов зависит. А чем проблемы раскроя не топ задача?
E>Ну пиши алгоритмы, решающие эту задачу. Просто нужны примеры КОНКРЕТНЫХ алгоритмов решающих КОНКРЕТНЫЕ задачи. Иначе разговор беспредметен.
Я не работаю с этими задачами, но в свое время интересовался.Максимум что делал это задача о рюкзаке. Но и там была куча вариаций без возможности полного перебора.
Поэтому мне понятна проблема с раскроем. Это более сложная задача, чем задача о рюкзаке.

S>> Почему прямоугольник или прямоугольный треугольник не является наследником фигуры с массивом точек?
E>Это неправильный вопрос. Правильный вопрос "зачем им быть такими наследниками"?

Нет есть реальное наследование. Прямоугольник это фигура. Все её свойства никуда не делись. Но добавились часные случаи, которыми проще оперировать.
И так может быть фигура не прямоугольником, но не может быть прямоугольника не фигурой. Мы можем работать с прямоугольником как с фигурой так и с прямоугольником зная его две стороны и угол наклона.
Если угол может быть всего в двух вариациях как 0 и 90 то еще проще с ним работать.

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

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

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

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

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

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

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

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

А когда ты этот код перегенерируешь ты точно вспомнишь, где ты раньше правил?

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

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

if Envelope is NOT Rectangular or Square

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Да я то полностью согласен. Вот в С++ нет разницы между структурой и классом. В Delphi Net Любой класс это наследник от Object. И вот здесь по неволе будешь использовать

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

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

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

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

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

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

S>>Степени свободы никуда не деваются — ведь треугольник вписать в прямоугольник тоже можно несколькими способами.
S>Интересно это скольким? По максимальной стороне и высоте?
Тремя. Для тупоугольного треугольника один из этих способов предпочтителен, т.к. он даёт минимальный процент отходов.
Для остроугольного и прямоугольного треугольников все три способа равнозначны с точки зрения отходов при раскрое.

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

S>А вот резать мы их будем по единому алгоритму.
Резать вы будете не те фигуры, которые воображались в процессе размещения, а те реальные, которые заказаны. В алгоритме реза никакого полиморфизма нет: это, грубо говоря, язык HP-GL — набор команд по перемещению режущего инструмента.

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

S> Вот кстати пример более сложного кроя, при том, что края материала криволинейной формы http://lemarse.spb.ru/products/cut_leather/
Это прекрасно. Видим, что алгоритм работает с одним примитивом — "лекало заданной формы". Что там у него внутри — ХЗ, но уж точно не то, о чём вы говорите — потому что прямоугольники размещаются под произвольными углами, а не с квантом в 90 градусов.
Восхищает ваша способность приводить нерелевантные аргументы.

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

S>Я вам уже сказал: в случае таких требований вы должны отказаться от полиморфизма.

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

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

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

S>Вообще-то у круга (который вы почему-то упорно называете окружностью) и квадрата две степени свободы — это их координаты x и y. При условии, что мы не рассматриваем крой с квадратами под произвольными углами.

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

Окружность — геометрическое место точек плоскости, удалённых от некоторой точки — центра окружности — на заданное расстояние, называемое радиусом окружности.
Окружность диаметра AB — это фигура, состоящая из точек A, B и всех точек плоскости, из которых отрезок AB виден под прямым углом.

Когда мы говорим о фигурах нам интересны внешние точки и их пересечение. Нас не интересуют точки внутри окружности, квадрата.

S>>У прямоугольника будет 4.

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

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

фигура

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

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

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

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

S>> Вот кстати пример более сложного кроя, при том, что края материала криволинейной формы http://lemarse.spb.ru/products/cut_leather/
S>Это прекрасно. Видим, что алгоритм работает с одним примитивом — "лекало заданной формы". Что там у него внутри — ХЗ, но уж точно не то, о чём вы говорите — потому что прямоугольники размещаются под произвольными углами, а не с квантом в 90 градусов.
S>Восхищает ваша способность приводить нерелевантные аргументы.
Угу если ты посмотришь повнимательней, то прямоугольники располагаются в большей частью параллельно сторонами.

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

А то зациклились, понимаешь, прямоугольник-квадрат. Шире надо смотреть, шире.

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

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

То, что оно не является решением задачи раскроя, вам понятно?

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

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

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

S>фигура

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

Shape Intersect(OtherShape)

Если мы оставим "прямоугольность" там, где она должна быть, т.е. в виде extension метода bool IsRect(this Shape), то любая программа корректно опознает прямоугольник в результате вызова метода Intersect на вот такой паре фигур:

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

)
S>А эта сторона будет всего одна. Для других фигур для этого может потребоваться больше усилий.
Зачем вы всё делаете наоборот? Если стоит задача опускать в почтовый ящик конверты произвольной формы, то вам придётся один раз сесть и написать алгоритм нахождения наименьшего диаметра.
Но как только вы его напишете, вам будет не нужен алгоритм поиска наименьшего диаметра для прямоугольника. Так что "больше усилий" потребуется как раз для "использования данных прямоугольника в своих алгоритмах". Вам же Егор уже дважды подробно написал ровно эту мысль. Объясните, что именно мешает вам эту мысль понять?

S>Тем, конечно, что композиция 1) не вводит отношения is-a, и 2) композиция работает на уровне объектов, а не классов. Побочным эффектом является возможность, в отличие от наследования, гибко выбирать тип компонуемого объекта.

Смешиваешь наследование интерфейса с наследованием реализации (может, конечно, это связано с тем, что в мейнстриме первое неотделимо от второго). Первое вводит отношение is-a, а наследование реализации никоим образом не вводит отношение is-a.

Наследование реализации вводит отношение "поведение подобно, но..". Наследование реализации квадрата от прямоугольника вводит отношение: поведение квадрата подобно поведению прямоугольника, но при условии, что стороны всегда равны.
Обратное наследование реализации прямоугольника от квадрата вводит отношение: поведение квадрата подобно, как у прямоугольника, но кроме поведения, которого следовало из равенства всех сторон.

При утверждении: A наследует реализацию от B (поведение A подобно поведению B, но за исключеним C) и представлении поведения в виде ориентированных графов отношение "поведение подобно, но" утверждает, что графы поведения A и B совпадают за исключением дуг, которые порождены условиями C.

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

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

S>> Да ради Стандартной Модели. От этого прямоугольник не перестал быть фигурой. До ООП, народ прекрасно обходился без классов.
E>Угу. И вот эта программа в стиле "без классов" будет лушче того ООП-шного варианта, который ты предлагаешь...

E>IMHO, у тебя вообще какая-то проблема с теМ, что перепутаны статика и динамика. ООП оно обычно на уровне типов, а не на уровне объектов работает жеж...

Почему, разве я не могу заложить алгоритм в фигуру для оптимального её расположения относительно рядом лежащих фигур?

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

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

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

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

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

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

S> Интересно а как ты квадрат то наследовать будешь?
Вы это в какой модели спрашиваете? В модели мутабельных объектов с наследованием реализации?
Или в модели иммутабельных АлгТД?

S> Это вырожденный прямоугольник у которого все стороны равны.
Ухты! А я-то всё думаю, что ж такое квадрат-то? А то все про него говорят, а я и не в курсе, что это такое.

S> Единственное его преймущество, что нужно знать всего одну сторону.
А недостатки квадрата можно озвучить?

S>Можно выразить любой квадрат в прямоугольник, но вот не любой прямоугольник можно выразить в квадрат.
S>У прмоугольника методы периметр, Площадь из квадрата никак не отнаследуешь.
ОМГ. Вы серъёзно?

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

Никаких проблем c наследованием, как только мы отказываемся от мутабельности.
Вот обратный вариант:

public class Square: Rectangle
{
  public Square(int a): base(a, a)
  {
  }
}

Он тоже прекрасно работает.

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

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

S>> Интересно а как ты квадрат то наследовать будешь?
S>Вы это в какой модели спрашиваете? В модели мутабельных объектов с наследованием реализации?
S>Или в модели иммутабельных АлгТД?

S>> Это вырожденный прямоугольник у которого все стороны равны.
S>Ухты! А я-то всё думаю, что ж такое квадрат-то? А то все про него говорят, а я и не в курсе, что это такое.

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

Наследование (которое может быть не виртуальным) и перекрытие виртуальных методов это не совсем одно и тоже.

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

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

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

Это он тебя подкалывает. Свойства у прямоугольника и квадрата разные, вот и все. В обсуждаемом контексте нет ни достоинств, ни недостатков у обоих фигур

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

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

S>Никаких проблем c наследованием, как только мы отказываемся от мутабельности.

Проблем становится меньше, но они все равно остаются. Если, конечно, речь идет о сохранении контракта родителя, а не просто о наследовании реализации.

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

Для пары квадрат/прямоугольник такого метода сходу не скажу, а для пары эллипс/круг он известен.

Метод "Получить_Оси_Симметрии" для эллипса возвращает тип Конечное_множество_известного_заранее_размера<2, Ось_Симметрии>, а для круга возвращает тип Неисчислимое_множество<Ось_Симметрии>.

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

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

Нарушаются контракты, инварианты.

Если возникает необходимость вводить для фигур унифицированый интерфейс, то с этим приходится иметь дело независимо от ЯП. Если такой необходимости нет, то в ФП можно взять ПМ, что Синклер и хочет сказать.

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

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

I>Это он тебя подкалывает. Свойства у прямоугольника и квадрата разные, вот и все. В обсуждаемом контексте нет ни достоинств, ни недостатков у обоих фигур

Разные? ))) Вообще то одно полное подмножество другого. )))

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

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

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

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

I>Нарушаются контракты, инварианты.

I>Если возникает необходимость вводить для фигур унифицированый интерфейс, то с этим приходится иметь дело независимо от ЯП. Если такой необходимости нет, то в ФП можно взять ПМ, что Синклер и хочет сказать.

Ну кроме ПМ есть такое понятие как утинная типизация или двойная Диспетчеризация. Я на 1С вполне доволен и двойной диспетчеризацией, ну ой как часто не хватает нормального ООП.
Даже ради интеллисенса. (Есть там слабенький вывод типов).
При этом общие методы приходится делать статическими с передачей в параметрах объекта. В 1С есть модуль Объекта типа методы объекта и модуль менеджера — статические методы
Наследование полей будет только в 83 (в 7.7 кстати они были изначально).

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

Ну вот ООП для Control мне очень нравится начиная с Delphi.
По теме я все же выскажусь так. Я за кодогенерацию например Т4. Сам активно использую в той же 1С. Я за общие DSL типа SQL, Linq где поведение этих DSL будет одинаково.
Что касается доморощенных DSL, то вот разбираться с ними будет намного сложнее, чем с кодом который они его скрывают.

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

I>>Это он тебя подкалывает. Свойства у прямоугольника и квадрата разные, вот и все. В обсуждаемом контексте нет ни достоинств, ни недостатков у обоих фигур

_>Разные? ))) Вообще то одно полное подмножество другого. )))

Конечно разные. Сможешь однозначно задать произвольный прямоугольник на плоскости с помощью всего двух точек — дам 100$

_>А если говорить по теме, то никакого наследования в этой задаче быть не должно в принципе. Т.к. класс прямоугольник полностью покрывает все возможные функции квадрата.

Как должно, никому не интересно. Интересно выжать максимум оптимизаций из этой разницы. Одну из оптимизаций я уже подсказал.

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

I>>Конечно разные. Сможешь однозначно задать произвольный прямоугольник на плоскости с помощью всего двух точек — дам 100$

_>Две точки — это 4 независимых числа. И прямоугольник и квадрат заданного размера задаются на плоскости 3-я числами. Соответственно размер у прямоугольника — это ещё 2 независимых числа, а у квадрата одно независимое числе (т.е. получаем те же самые 4). Таким образом получаем всё тоже самое, но с сохранением единого интерфейса. Чудес в математики не бывает. )))

А на деле получается так — (0,0) — (1,3) это ровно один квадрат и при этом бесконечное количество прямоугольников.

Вот тебе и "подмножество".

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

S>По теме я все же выскажусь так. Я за кодогенерацию например Т4. Сам активно использую в той же 1С. Я за общие DSL типа SQL, Linq где поведение этих DSL будет одинаково.
S>Что касается доморощенных DSL, то вот разбираться с ними будет намного сложнее, чем с кодом который они его скрывают.
А чем твоя кодогенерация на T4 не доморощенный ДСЛ?

... << RSDN@Home 1.2.0 alpha 5 rev. 62>>

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

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

I>Вот тебе и "подмножество".

Ой, ну что за детский сад, а? ) Это как раз и есть подмножество, т.к. один из этого бесконечного количества и есть наш квадрат. ))) Ну или если говорить языком программирования... Делаем конструктор для нашего класса прямоугольника в виде Rectangle(Point p1, Point p2, double k). И соответственно для квадрата вызываем его как Rectangle(p1, p2, 1).

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

I>>Вот тебе и "подмножество".

_>Ой, ну что за детский сад, а? ) Это как раз и есть подмножество, т.к. один из этого бесконечного количества и есть наш квадрат. ))) Ну или если говорить языком программирования... Делаем конструктор для нашего класса прямоугольника в виде Rectangle(Point p1, Point p2, double k). И соответственно для квадрата вызываем его как Rectangle(p1, p2, 1).

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

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

Ну если ты все еще сомневаешься, то покажи окружность, вписаную в прямоугольник(который квадратом не является) ну и покажи как унифицировать такой интерфейс.

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

DG>У наследника для некоторых методов может меняться тип результата, что разрушает контракт родителя.
DG>Для пары квадрат/прямоугольник такого метода сходу не скажу, а для пары эллипс/круг он известен.
DG>Метод "Получить_Оси_Симметрии" для эллипса возвращает тип Конечное_множество_известного_заранее_размера<2, Ось_Симметрии>

Не подходит для эллипса, который есть окружностью.

DG>, а для круга возвращает тип Неисчислимое_множество<Ось_Симметрии>.

IO>Не подходит для эллипса, который есть окружностью.

во-первых, это вопрос терминологии. Или эллипс есть невырожденный эллипс с a != b и a > 0, b > 0, или эллипс есть обобщенный эллипс, включающий в себя в том числе и все вырожденные случаи: круг (a=b a,b!= 0), точка (a=b=0), "двойной" отрезок (a=0,b != 0 или a!=0, b=0)
во-вторых, проблема в любом случае остается и для пары обобщенный эллипс и обобщенный круг. Потому что для обобщенного эллипса метод "Получить_Оси_Симметрии" имеет возвращаемый тип Union<Конечное_множество_известного_заранее_размера<2, Ось_Симметрии>, Неисчислимое_множество<Ось_Симметрии>>, а для обобщенного круга данный метод имеет возвращаемый тип Неисчислимое_множество<Ось_Симметрии>

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

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

S>>По теме я все же выскажусь так. Я за кодогенерацию например Т4. Сам активно использую в той же 1С. Я за общие DSL типа SQL, Linq где поведение этих DSL будет одинаково.
S>>Что касается доморощенных DSL, то вот разбираться с ними будет намного сложнее, чем с кодом который они его скрывают.
WH>А чем твоя кодогенерация на T4 не доморощенный ДСЛ?

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

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

S>Здравствуйте, Serginio1, Вы писали:
S>>Как я уже и писал выше проще наследоваться от абстрактного класса Фигура. А по твоему подходу можно наследоваться хоть от треугольника, все равно виртуальные методы перекрываются. Это ничем не отличается от интерфейсов. Все таки наследование это в первую очередь наследование существующей реализации и структуры полей, с добавлением дополнительных свойств(полей) и методов.
S>Нет. Я не хочу опять заниматься очередным ликбезом, поэтому отвечу кратко: наследование — это отношение "is-a". И наследование реализации — один из худших видов наследования.
S>А про то, что проще, а что сложнее, рассуждать вообще не имеет смысла до тех пор, пока не поставлена задача.
Ну да. Вот например тебе в наследство достался член. Но ты то ли из-за каких то проблем с размером решил этот член отрезать и вместо него пришить новый.
Ну во первых это опасно для здоровья, а во вторых как многими доказано размер не имеет значения. Зачем плодить лишние сущности?
А задач таких полно. Например Control, Документы в БД (можно выделять разные виды доументов (складские, финансовые итд), у которых есть одинаковые сущности и поведение. Легче в базовом классе прописать реализацию, а в новых только дополнять или изменять только те методы специфичные для данного документа. Например печать. И то в процессе печати могут использоваться в основном неперекрытые методы, так и перекрываемы, для формирования дополнительного вывода секций. Наследованиеи полиморфизмвыделены отдельно. Например в 1С приходится использовать полиморфизм через использование названия одинаковых методов и свойств. Но это далеко не ООП

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

Если для тебя наследование реализации — один из худших видов наследования, то для меня все наоборот. Меня интересует минимум написания кода при введении нового элемента в иерархию.
Кстати в Delphi есть такой подход как виртуальные методы класса.
S>>С Введением интерфейсов, перекрытие в ООП ушло на второй план.
S>Ну-ну.
Ну и в чем различие между Интерфейсом и наследованием VMT если все методы перекрываются? Только в организации доступа к этим таблицам.

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

IO>>Не подходит для эллипса, который есть окружностью.
DG>во-первых, это вопрос терминологии. Или эллипс есть невырожденный эллипс с a != b и a > 0, b > 0,

Странно когда родительский класс не представляет частные случаи, которые представляют потомки. В таких случаях потомок "не есть" родитель. Значит потомок не представляет подмножество родителя, а родитель не есть более общее понятие относительно потомка. И наследование здесь не должно применяться.
Можно конечно унаследовать квадрат от крокодила, все перекрыть... Но мы же говорим о проблемах ООП при правильном применении, а не о проблемах антипаттернов.

DG> или эллипс есть обобщенный эллипс, включающий в себя в том числе и все вырожденные случаи: круг (a=b a,b!= 0), точка (a=b=0), "двойной" отрезок (a=0,b != 0 или a!=0, b=0)

Именно такой, каким он описан в математике, не плодим сущности.

DG>во-вторых, проблема в любом случае остается и для пары обобщенный эллипс и обобщенный круг. Потому что для обобщенного эллипса метод "Получить_Оси_Симметрии" имеет возвращаемый тип Union<Конечное_множество_известного_заранее_размера<2, Ось_Симметрии>, Неисчислимое_множество<Ось_Симметрии>>, а для обобщенного круга данный метод имеет возвращаемый тип Неисчислимое_множество<Ось_Симметрии>

Такой тип не нужен, так как Ваш Union может представить такие обьекты подмножеством своих значений.
Может в таких случаях метод потомка должен возвращать подтип метода предка?

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

S>Если общие DSL изучают все
Потому что Domain общий.

S>, то для доморощенного нужно тратить время на обучение, вникание и не всем это посильно.
Конкретный Domain тоже нужно изучить.
Легче это сделать когда уже есть хоть какой-то язык.

S> Самому (и не только мне одному) кстати проще переписать, чем поддерживать чей то невнятный код.
Либу тоже проще переписать? Зачастую проще переписать, потому что сложно (или лень) понять

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

S>> Самому (и не только мне одному) кстати проще переписать, чем поддерживать чей то невнятный код.
IO>Либу тоже проще переписать? Зачастую проще переписать, потому что сложно (или лень) понять

Да нет стараешься понять (это же и тренировка ума, и просмотр новых подходов) и считаю, что переписывать код это последнее средство. Переписывать это тоже не легкий путь. Так или иначе все равно приходится разбираться с кодом. Так вот иногда взвесив затраты на переписывание и поддержку делаешь то, что для тебя выгодней.
Как и в случае с DSL все зависит от конкретной ситуации. Все плюсы и минусы здесь уже были озвучены. А решение принимает ответственный за проект.

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

S>Здравствуйте, Serginio1, Вы писали:
S>> Ну да. Вот например тебе в наследство достался член. Но ты то ли из-за каких то проблем с размером решил этот член отрезать и вместо него пришить новый.
S>>Ну во первых это опасно для здоровья, а во вторых как многими доказано размер не имеет значения. Зачем плодить лишние сущности?
S>~~Идиотские~~ некорректные аналогии обсуждать не будем.

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

S>> Ну не везде и не всегда. Я вот сейчас работаю на мебельной фабрике. Там есть программы для оптимального расположения фигур для резки, с минимальными количествами отходов.
S>>Но в основном эти фигуры являются прямоугольниками и нет большого смысла городить огород со сложными фигурами. В любом случае их проще вписать в прямоугольники для упрощения алгоритма (криволинейный крой).
S>Ну вот видите, в вашем алгоритме нет никаких иерархий фигур. Фигура определяется реальной формой (поликривая) и её bounding rectangle.
S>>И квадрат в этом случае ничем от прямоугольника не отличается.
S>Как, впрочем, и от круга, эллипса, звезды Соломона и профиля Руссиновича.
S>>Хотя есть и программы которые работают со сложными фигурами, но вот алгоритм там совсем другой, более сложный и затратный. Но вот им в реальных условиях не пользуются.
S>И даже в нём нет никаких иерархий фигур.

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

S>> Если для тебя наследование реализации — один из худших видов наследования, то для меня все наоборот. Меня интересует минимум написания кода при введении нового элемента в иерархию.
S>Совершенно верно. Именно поэтому наследование реализации — зло: при нём введение нового элемента в иерархию может затронуть неограниченный объём кода. Ведь элемент может появиться не только в листе. Любое изменение в базовом классе начинает распространяться на всех наследников как степной пожар.
А что в этом плохого, если на начальном этапе была ошибка? Ты исправил в одном месте вместо во всей иерархии. Для примера есть единый код который дергает виртуальные методы. Ну и понадобилось что то изменить в этом методе например журнал регистрации действий. Чем это плохо. Все зависит от правильности архитектуры приложения.

Для примера с документами. Например изнаально был только один метод списания ФИФО, но в будущем понадобилось списание по ЛИФО. Так изменяя алгоритм в базовом классе ты приводишь к нужному поведению всех документов.

Ты кстати по поводу контролов почему то не прошелся.

S>>Кстати в Delphi есть такой подход как виртуальные методы класса.
S>Я в курсе. И связано это с понятием "ссылки на класс", которого нет в других языках программирования. Фактически, в Delphi есть две параллельных иерархии наследования — классов и метаклассов. В дотнете Хейльсберг решил этим не задуряться.
А может ему не дали?

S>> Ну и в чем различие между Интерфейсом и наследованием VMT если все методы перекрываются? Только в организации доступа к этим таблицам.
S>Вы слишком много внимания уделяете несущественным деталям, вроде VMT и организации доступа. Это вам мешает.
S>Наследование реализации — это в том числе и наследование состояния, чего нет в случае реализации интерфейса.
Ну так в твоем случае прямоугольник квадрат наследования ни состояния ни реализации нет.

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

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

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

S> Для примера с документами. Например изнаально был только один метод списания ФИФО, но в будущем понадобилось списание по ЛИФО. Так изменяя алгоритм в базовом классе ты приводишь к нужному поведению всех документов.
А если бы с самого начала метод списания был во внешнем хелпер-методе, то ничего изменять в базовом классе бы вообще не пришлось. И не потребовалось бы перетестировать всех наследников на предмет того, не сломался ли кто-то из них из-за некорректно перекрытого виртуального метода. Более того, можно было бы применять обе стратегии в зависимости от конкретных условий — например, документы до часа Ч проводятся по FIFO, а после — по LIFO. Подобная гибкость при наследовании труднодостижима.

S>Ты кстати по поводу контролов почему то не прошелся.
Неинтересно.

S> Ну так в твоем случае прямоугольник квадрат наследования ни состояния ни реализации нет.
Я привёл два случая.

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

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

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

>> А у прямоугольника они не под прямым что ли пересекаются? ))) Равенство сторон приводит только к общей точке пересечения.
I>

Нет и это очевидно любому кто учил геометрию. Эту разницу можно использовать для оптимизации.
I>Собтсвенно после такого ляпа можно и разговор заканчивать, но я нынче добр

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

I>Мне просто кажется ты привык к своим задачам и ничего дальше даже не хочешь рассматривать. Я собственно не утверждаю, что класс квадрат надо вводить в любом случае. В качестве оптимизаций — запросто, существенно упрощает логику, т.е. не надо будет обкладывать логику проверками, исключениями и прочей мутью, когда большая часть вычислений завязана на свойства именно квадрата, а не прямоугольника.

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

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

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

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

Кстати и в 1С стараются применять утинную типизацию. Но это костыли.

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

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

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

S>> Для примера с документами. Например изнаально был только один метод списания ФИФО, но в будущем понадобилось списание по ЛИФО. Так изменяя алгоритм в базовом классе ты приводишь к нужному поведению всех документов.
S>А если бы с самого начала метод списания был во внешнем хелпер-методе, то ничего изменять в базовом классе бы вообще не пришлось. И не потребовалось бы перетестировать всех наследников на предмет того, не сломался ли кто-то из них из-за некорректно перекрытого виртуального метода. Более того, можно было бы применять обе стратегии в зависимости от конкретных условий — например, документы до часа Ч проводятся по FIFO, а после — по LIFO. Подобная гибкость при наследовании труднодостижима.
А зачем тестировать если они являются наследниками и у них общая часть для списаний по партиям? Я уже выше писал про такие хэлперы в 1С.
А кто мешает стратегию применить в базовом классе? Интерфейсы в большинстве случаев более сложный вариант и нет у него преймуществ перед иерархией классов.
S>>Ты кстати по поводу контролов почему то не прошелся.
S>Неинтересно.
А мне очень нравится организация Контрололв.

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

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

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

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

S>Кстати и в 1С стараются применять утинную типизацию. Но это костыли.
При чём тут утиная типизация?

S> Ну вот форма может быть близкой к треугольнику, прямоугольнику, овалу, серпу итд. И соответственно наследоваться от этих фигур. Либо иметь функцию трансформации в такую фигуру.
Простите, это чушь. "Функция трансформации" определяется не тем, кто от кого отнаследован, а степенью близости к определённой форме. К примеру, овал одной формы будет близок к прямоугольнику, а другой формы — к кругу. Под близостью я понимаю отношение площади фигуры к площади покрывающей её фигуры "упрощённой" формы. Ну так вот в таком подходе совершенно непонятно, от кого наследовать овал — от прямоугольника или от круга. Это показывает ущербность идеи вообще применять наследование для этих целей.

S> Я уже приводил пример со списанием по партиям. Какое там нарушение логики, если правильно спроектировани базовый класс, а наследники отвечают за дополнительную часть?
А откуда вы знаете, что наследники корректно отвечают за "дополнительную" часть? Без перетестирования вы этого никак не узнаете.

S>Другое дело, что документы могут быть смешанными. Например и складскими так и взаиморасчеты с клиентами. И приходится применять разные тактики. Например можно трансформировать в объект другого класса, можно применить интерфейсы итд.
А можно спроектировать так, чтобы не вносить лишних зависимостей. Трансформировать в объект другого класса нельзя — вы потеряете идентичность. Если у вас зародилась идея поменять класс, сохранив идентичность, то лучше убейте её в зародыше, т.к. она взорвёт всю объектную модель. Вы потеряете типобезопасность — т.е. какие-то ссылки на объект класса А внезапно окажутся ссылками на объект класса Б. В лучшем случае вы получите cast exception в рантайме; в более плохом вы будете применять неподходящие методы.
Поверьте мне на слово — я норматив на мастера спорта в этом выпиливании лобзиком по вазелину выполнил ещё тогда, когда 1с под стол пешком ходил.

S>Но чем больше инструментов тем проще работать.
Нет. Преумножение сущностей без необходимости только затрудняет работу.

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

S> А мне очень нравится организация Контрололв.
А мне — нет. Всю жизнь меня бесило то, что в одних контролах есть, скажем, дабл-клик евент, а в других — нету. И всё, сиди кури. Или допиливай очередного наследника, в которого ты копи-пейстом будешь переносить эту убогую стейт-машину.
Ну, теперь-то мы знаем, как это правильно делать, слава Rx. Но в "чистом ООП" иерархии контролов — полная хрень.

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

S> То есть ты считаешь что ООП не нужно?
Я считаю, что большинство программистов неверно понимают ООП — спасибо идиотской пропаганде заблуждений.
S>Да здравствует утинная типизация (интерфейсы это просто типизированный контракт). И мыслить не реальными категориями наследования которые присутствуют в реальной жизни, а городить костыли непонятно зачем.
В реальной жизни нет категорий наследования, которые поддерживаются в ООП. Вас обманули.
Те же типы документов построить в дерево крайне тяжело. И да, "утиная типизация" для них подходит лучше, чем многая другая. Грубо говоря потому, что от документа для какого-либо процесса обычно требуется иметь некий набор атрибутов. При этом у одного типа документов могут быть атрибуты А и Б, у другого — Б и В, а у третьего — А и В. И кого от кого тут наследовать — совершенно непонятно.

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

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

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

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

Чего?

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

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

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

S>> Я уже приводил пример со списанием по партиям. Какое там нарушение логики, если правильно спроектировани базовый класс, а наследники отвечают за дополнительную часть?
S>А откуда вы знаете, что наследники корректно отвечают за "дополнительную" часть? Без перетестирования вы этого никак не узнаете.

А тем, что для алгоритма нужно знать только базовые данные от которого зависит первичный алгоритм. Например для списания по ЛИФО нужны те же данные, что и списание по ФИФО.

S>>Другое дело, что документы могут быть смешанными. Например и складскими так и взаиморасчеты с клиентами. И приходится применять разные тактики. Например можно трансформировать в объект другого класса, можно применить интерфейсы итд.
S>А можно спроектировать так, чтобы не вносить лишних зависимостей. Трансформировать в объект другого класса нельзя — вы потеряете идентичность. Если у вас зародилась идея поменять класс, сохранив идентичность, то лучше убейте её в зародыше, т.к. она взорвёт всю объектную модель. Вы потеряете типобезопасность — т.е. какие-то ссылки на объект класса А внезапно окажутся ссылками на объект класса Б. В лучшем случае вы получите cast exception в рантайме; в более плохом вы будете применять неподходящие методы.
S>Поверьте мне на слово — я норматив на мастера спорта в этом выпиливании лобзиком по вазелину выполнил ещё тогда, когда 1с под стол пешком ходил.

Ну вот пример. Для того, что бы использовать функцию хэлпер, данные должны быть сгруппированы в некую структуру имеющие в том числе и табличные части. Это ничем не отличается от Интерфейса.
Для примера есть контракт который имеет 100 свойств. Мне проще создать объект у которого заполнить только 3 свойства, а остальные заполнить по умолчанию, вместо того, что бы городить интерфейс и реализовывать все 100 свойств. Ничего в типобезопасности я не потеряю. Для примера в NET прекрасно пользуются трансформаторы например IEnumerator IEnumerable.GetEnumerator() который в 99 процентов случаев создает класс оболочку.
Мало того, когда данные применяются только для чтения, то и создание того объекта ничем не отличается от DataSet ов и прочих структур. Просто к классу уже привязаны функции и можно использовать интелиссенс и прочие вкусности. Просто в качестве нужной ссылки будет не this, а другое поле ссылающееся на оригинал.

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

S>> То есть ты считаешь что ООП не нужно?
S>Я считаю, что большинство программистов неверно понимают ООП — спасибо идиотской пропаганде заблуждений.
S>>Да здравствует утинная типизация (интерфейсы это просто типизированный контракт). И мыслить не реальными категориями наследования которые присутствуют в реальной жизни, а городить костыли непонятно зачем.
S>В реальной жизни нет категорий наследования, которые поддерживаются в ООП. Вас обманули.
S>Те же типы документов построить в дерево крайне тяжело. И да, "утиная типизация" для них подходит лучше, чем многая другая. Грубо говоря потому, что от документа для какого-либо процесса обычно требуется иметь некий набор атрибутов. При этом у одного типа документов могут быть атрибуты А и Б, у другого — Б и В, а у третьего — А и В. И кого от кого тут наследовать — совершенно непонятно.

Есть складские документы. У которых есть свойство склад и табличная часть товары одинаковая состав полей базоваго класса одинаков для всех. Вот и приходится для создания нового документа просто копировать документ только добавляя в него новые. Так что у всех будут поля А,Б,В. А вот другие поля могут быть различными даже при одинаковом названии.
И таких копи пастов в 1С пруд пруди.

Ну и многое решается на уровне виртуальных свойств.

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

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

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

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

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

S>Чего?
Я уже писал, что для того что бы создать новый документ, я беру близкий к нему просто копирую и добавляю новые поля. Вместо того, что бы отнаследоваться и добавить новое поле.
Если я в базовом классе добавлю поле, то мне без наследования придется добавлять во все классы это поле. Как я это делаю в 1С 8 ке.

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

I>Имелось ввиду, что диагональ есть биссектриса.

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

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

I>С этого все и начиналось — "В качестве оптимизаций".

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

Здравствуйте, Serginio1, Вы писали:
S> Интерфейс это по сути и есть та самая утиная типизация.
Нет. Не надо наделять общепринятые термины вашими личными определениями.

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

S> А тем, что для алгоритма нужно знать только базовые данные от которого зависит первичный алгоритм. Например для списания по ЛИФО нужны те же данные, что и списание по ФИФО.
Ну, то есть всё строится на вашей внутренней уверенности. Простите, для промышленной разработки этого недостаточно.

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

S>Для примера есть контракт который имеет 100 свойств. Мне проще создать объект у которого заполнить только 3 свойства, а остальные заполнить по умолчанию, вместо того, что бы городить интерфейс и реализовывать все 100 свойств.
Совершенно непонятно, зачем вам потребовались остальные 97 свойств в этом "контракте", если для успешной работы вполне хватает трёх. Похоже, что вы ошиблись при проектировании контракта, и теперь исправляете ошибку при помощи костылей.

S>Ничего в типобезопасности я не потеряю. Для примера в NET прекрасно пользуются трансформаторы например IEnumerator IEnumerable.GetEnumerator() который в 99 процентов случаев создает класс оболочку.
Не понял, о каком трансформаторе вы говорите? Вы, кстати, в курсе, я надеюсь, что foreach — одно из немногих мест в C# 1.0, где применяется реальная утиная типизация?

S>Тогда я должен это прописать в методе хэлпере. Чем метод хэлпера отличается от классового метода?
Тем, что его можно применить не только к потомкам конкретного класса. Это улучшает cohesion и снижает coupling.

S> Есть складские документы. У которых есть свойство склад и табличная часть товары одинаковая состав полей базоваго класса одинаков для всех. Вот и приходится для создания нового документа просто копировать документ только добавляя в него новые. Так что у всех будут поля А,Б,В. А вот другие поля могут быть различными даже при одинаковом названии.
А есть и другие документы, у которых нет свойства "склад". Тем не менее, это не мешает им иметь некоторые общие черты со складскими документами.
S>И таких копи пастов в 1С пруд пруди.
Ну и что? С каких пор 1С стал образцом для подражания?
S> Ну и многое решается на уровне виртуальных свойств.
Проблема, которую я обозначил, не решается на уровне виртуальных свойств.

S> Это не приделывание. Если ты моделируешь походку для абстрактного класса человек, то она будет так же применена для его наследников женщина и мужчина.
Если я идиот — да. А если нет — то походка будет моделироваться системой решений задач инверсной кинематики, а объект "человек" независимо от пола будет всего лишь описывать кинематическую схему. Никакого наследования женщины от человека у меня не будет, а будет конструирование через клонирование образцов, а также конструкторы "людей" по заданным параметрам — типа пол, рост, ширина бёдер и т.п.

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

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

S> Я уже писал, что для того что бы создать новый документ, я беру близкий к нему просто копирую и добавляю новые поля. Вместо того, что бы отнаследоваться и добавить новое поле.
А лишние поля вы что, при этом не удаляете?
Кстати, вы сейчас про экземпляр документа или про класс документа?
S>Если я в базовом классе добавлю поле, то мне без наследования придется добавлять во все классы это поле. Как я это делаю в 1С 8 ке.
Зачем?

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

S>Здравствуйте, Serginio1, Вы писали:
S>> Интерфейс это по сути и есть та самая утиная типизация.
S>Нет. Не надо наделять общепринятые термины вашими личными определениями.
Интерфейс это контракт. Я уже давно говорю об псевдоинтерфейсах для объектов с двойной диспетчиризацией.
Дисп интерфейс например это не является Интерфейсом но уберает одну степень диспетчеризациии и вводит типизацию. Так применяя псевдоинтерфейсы к таким объектам можно использовать интеллисенс и вывод типов.
Кстати Воронков Василий в свое время делал обертку на рефлекшине для утинной типизации класса на C#.
Интерфейс это контракт на уровне VMT, утинная типизация это тоже контракт но на уровне названий полей и методов. Зная контракт можно легко из утинной типизации сделать интерфейс и обратно.

S>> Есть базовый класс с массивом точек по которому можно построить фигуру, На основании их можно построить создать простые формы. Можно для каждой фигуры выбирать близкий по виду. Как правило самый простой алгоритм это прямоугольники. Затем прямоугольники с треугольниками итд. Для обсчета нужны простые фигуры. Фигуры по своей сути не наследуются, но там возможны функции трансформации.
S>Ключевое выделено.
Но это не значит, что треугольник, чем то отличается от базового класса имеющего массив точек для соединения. Это нужно для резки. А для раскроя проще пользоваться более простыми фигурами.
Взе зависит от задачи.

S>> А тем, что для алгоритма нужно знать только базовые данные от которого зависит первичный алгоритм. Например для списания по ЛИФО нужны те же данные, что и списание по ФИФО.
S>Ну, то есть всё строится на вашей внутренней уверенности. Простите, для промышленной разработки этого недостаточно.
Ну 1С то так и делает. Для примера все документы наследуются от базового класса. Все объекты имеют базовый набор полей итд, и методы . Все регистры тоже самое.
Да там иерархия на одно поколение но все же.

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

S>>Для примера есть контракт который имеет 100 свойств. Мне проще создать объект у которого заполнить только 3 свойства, а остальные заполнить по умолчанию, вместо того, что бы городить интерфейс и реализовывать все 100 свойств.
S>Совершенно непонятно, зачем вам потребовались остальные 97 свойств в этом "контракте", если для успешной работы вполне хватает трёх. Похоже, что вы ошиблись при проектировании контракта, и теперь исправляете ошибку при помощи костылей.
В зависимости от кучи показателей требуется тот или иной алгоритм. И писать его лучше в одном месте.

S>>Ничего в типобезопасности я не потеряю. Для примера в NET прекрасно пользуются трансформаторы например IEnumerator IEnumerable.GetEnumerator() который в 99 процентов случаев создает класс оболочку.
S>Не понял, о каком трансформаторе вы говорите? Вы, кстати, в курсе, я надеюсь, что foreach — одно из немногих мест в C# 1.0, где применяется реальная утиная типизация?
Я говорю об преобразовании из одного типа объекта в другой. Например окружность в квадрать. Int в Double.

S>>Тогда я должен это прописать в методе хэлпере. Чем метод хэлпера отличается от классового метода?
S>Тем, что его можно применить не только к потомкам конкретного класса. Это улучшает cohesion и снижает coupling.
А кто мешает применить этот интерфейс и к классу? Заметь что в обычном классе обычно дублируются обычные методы и интерфейсные.
Только в классах потомках не нужно заново переопределять методы.

S>> Есть складские документы. У которых есть свойство склад и табличная часть товары одинаковая состав полей базоваго класса одинаков для всех. Вот и приходится для создания нового документа просто копировать документ только добавляя в него новые. Так что у всех будут поля А,Б,В. А вот другие поля могут быть различными даже при одинаковом названии.
S>А есть и другие документы, у которых нет свойства "склад". Тем не менее, это не мешает им иметь некоторые общие черты со складскими документами.
S>>И таких копи пастов в 1С пруд пруди.
S>Ну и что? С каких пор 1С стал образцом для подражания?
Ну вот ты то агитируешь за такой подход.

S>> Ну и многое решается на уровне виртуальных свойств.
S>Проблема, которую я обозначил, не решается на уровне виртуальных свойств.

Ты исходишь из того, что нет реального наследования. Я исхожу из того, что такая иерархия существует.

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

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

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

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

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

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

S>Кстати, вы сейчас про экземпляр документа или про класс документа?
S>>Если я в базовом классе добавлю поле, то мне без наследования придется добавлять во все классы это поле. Как я это делаю в 1С 8 ке.
S>Зачем?
А куда мне деваться если понадобились новые алгоритмы записи в новые регистры, для которых нужны дополнительные свойства. Все течет все изменяется.

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

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

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

S>Кстати Воронков Василий в свое время делал обертку на рефлекшине для утинной типизации класса на C#.
А IT довёл идею до конца и в BLT есть решение для утиной типизации на основе Reflection.Emit.
Ну и в 4.0 у нас есть dynamic, с которым как бы всё стало частью платформы.

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

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

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

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

S>>Совершенно непонятно, зачем вам потребовались остальные 97 свойств в этом "контракте", если для успешной работы вполне хватает трёх. Похоже, что вы ошиблись при проектировании контракта, и теперь исправляете ошибку при помощи костылей.
S> В зависимости от кучи показателей требуется тот или иной алгоритм. И писать его лучше в одном месте.
Вы не ответили на вопрос.

S>>>Ничего в типобезопасности я не потеряю. Для примера в NET прекрасно пользуются трансформаторы например IEnumerator IEnumerable.GetEnumerator() который в 99 процентов случаев создает класс оболочку.
S>>Не понял, о каком трансформаторе вы говорите? Вы, кстати, в курсе, я надеюсь, что foreach — одно из немногих мест в C# 1.0, где применяется реальная утиная типизация?
S> Я говорю об преобразовании из одного типа объекта в другой. Например окружность в квадрать. Int в Double.
И какое отношение к преобразованию int в double имеет IEnumerator IEnumerable.GetEnumerator()?

S> А кто мешает применить этот интерфейс и к классу? Заметь что в обычном классе обычно дублируются обычные методы и интерфейсные.
Какой "этот интерфейс"?

S>>Ну и что? С каких пор 1С стал образцом для подражания?
S> Ну вот ты то агитируешь за такой подход.
За какой подход?

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

S> Правильно. Но вот моделировать роды ты можешь только для женщины.
И по-прежнему не будет никакой иерархии наследования.

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

S> Да не промыли мне мозги. Просто как раз я вынужден обходиться без ООП и мне его сильно не хватает.
Промыли-промыли. Вам кажется, что вам не хватает ООП, а на самом деле вам не хватает в основном антипаттернов.
Настоящее ООП — оно вовсе не такое, как описано в учебниках из 90х.

Здравствуйте, Serginio1, Вы писали:
S> А их нет. Либо имеют длину 0. Например в 1С существуют свойства код и наименование,Владелец но они могут быть не во всех справочниках. При этом при вызове будет вызвано исключение.
S>Как я говорил раньше это решается через вирткальные свойства.
Как по мне, так это отвратительное решение. То есть вы даёте документу свойства, которых у него заведомо нет, и обруливаете это при помощи выброса исключения в рантайме. Зачем? Только ради того, чтобы уложить классы в прокрустово ложе иерархии наследования?

S>>>Если я в базовом классе добавлю поле, то мне без наследования придется добавлять во все классы это поле. Как я это делаю в 1С 8 ке.
S>>Зачем?
S> А куда мне деваться если понадобились новые алгоритмы записи в новые регистры, для которых нужны дополнительные свойства. Все течет все изменяется.
И как вы примените эти новые алгоритмы записи к существующим документам, в которых не было этих дополнительных свойств?

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

I>>С этого все и начиналось — "В качестве оптимизаций".

_>Да, да, оптимизации расхода памяти — это конечно ключевой момент в дискуссии о преимуществах использования наследования при проектирование архитектуры.

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

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

S>>Кстати Воронков Василий в свое время делал обертку на рефлекшине для утинной типизации класса на C#.
S>А IT довёл идею до конца и в BLT есть решение для утиной типизации на основе Reflection.Emit.
S>Ну и в 4.0 у нас есть dynamic, с которым как бы всё стало частью платформы.
Угу при этом никакого интелиссенса и проверки типов.
Кстати у Василия тоже на эмите http://www.rsdn.ru/forum/src/3165397

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

Почему? Треугольник как раз и является наследником фигуры с массивом точек. Разве не так?
S>> Ну 1С то так и делает. Для примера все документы наследуются от базового класса. Все объекты имеют базовый набор полей итд, и методы . Все регистры тоже самое.
S>>Да там иерархия на одно поколение но все же.
S>И это вполне оправдано в тех случаях, когда реально есть поведение, которое хочется получить от всех участников иерархии.

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

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

S>>>>Ничего в типобезопасности я не потеряю. Для примера в NET прекрасно пользуются трансформаторы например IEnumerator IEnumerable.GetEnumerator() который в 99 процентов случаев создает класс оболочку.
S>>>Не понял, о каком трансформаторе вы говорите? Вы, кстати, в курсе, я надеюсь, что foreach — одно из немногих мест в C# 1.0, где применяется реальная утиная типизация?
S>> Я говорю об преобразовании из одного типа объекта в другой. Например окружность в квадрать. Int в Double.
S>И какое отношение к преобразованию int в double имеет IEnumerator IEnumerable.GetEnumerator()?
А тем что всето приведения к интерфейсу, можно этот интерфейс запросить через GetIntefaсe<T>()

S>> А кто мешает применить этот интерфейс и к классу? Заметь что в обычном классе обычно дублируются обычные методы и интерфейсные.
S>Какой "этот интерфейс"?
Универсальный Интерфейс который должны поддерживать все классы вне иерархии.

S>>>Ну и что? С каких пор 1С стал образцом для подражания?
S>> Ну вот ты то агитируешь за такой подход.
S>За какой подход?
За подход без наследования.

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

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

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

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

S>Здравствуйте, Serginio1, Вы писали:
S>> А их нет. Либо имеют длину 0. Например в 1С существуют свойства код и наименование,Владелец но они могут быть не во всех справочниках. При этом при вызове будет вызвано исключение.
S>>Как я говорил раньше это решается через вирткальные свойства.
S>Как по мне, так это отвратительное решение. То есть вы даёте документу свойства, которых у него заведомо нет, и обруливаете это при помощи выброса исключения в рантайме. Зачем? Только ради того, чтобы уложить классы в прокрустово ложе иерархии наследования?
Это не прокрустово ложе, а вырождение. В той же природе у наследников могут вырождаться хвост, волосянной покров итд.

S>>>>Если я в базовом классе добавлю поле, то мне без наследования придется добавлять во все классы это поле. Как я это делаю в 1С 8 ке.
S>>>Зачем?
S>> А куда мне деваться если понадобились новые алгоритмы записи в новые регистры, для которых нужны дополнительные свойства. Все течет все изменяется.
S>И как вы примените эти новые алгоритмы записи к существующим документам, в которых не было этих дополнительных свойств?
Приходится либо полностью перепроводить по одному измененному регистру (в 8 ке это можно), либо оставлять по умолчанию. Либо начинать записывать с даты внесения этих реквизитов.
Вариантов куча.

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

I>

Поздравляю вас с успешным завалом выпускного экзамена по геометрии за 9й класс.
Вот вам картинка про биссектрисы углов в прямоугольнике — медитируйте до просветления:

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

S> Почему? Треугольник как раз и является наследником фигуры с массивом точек. Разве не так?
Ещё раз намекну: это зависит от того, какой контракт вы хотите получить от фигуры и от треугольника.
Если в контракт фигуры входит (естественная для мутабельных объектов) операция "void insertPoint(Point newPoint, int position)", то треугольник отнаследовать от этой фигуры никак не получится.
Если фигура — immutable, то в её контракт такая операция входить не может.
Зато может входить операция типа int getArea(). Но её не имеет смысла делать полиморфной, поэтому наследование треугольника вовсе не нужно. Достаточно иметь метод типа

Shape CreateTriangle(Point a, Point b, Point c)

;
Наследование нужно там, где нужен полиморфизм и возможность подстановки. В геометрии таких задач нет.

S>>Вы не ответили на вопрос.
S> Не хватает трех, а эти три отличаются от дефолтных.
Вы по-прежнему не ответили на вопрос.

S>>И какое отношение к преобразованию int в double имеет IEnumerator IEnumerable.GetEnumerator()?
S> А тем что всето приведения к интерфейсу, можно этот интерфейс запросить через GetIntefaсe<T>()
Ну это совсем другое. Посмотрите внутрь GetEnumerator для интереса.

S>>Какой "этот интерфейс"?
S> Универсальный Интерфейс который должны поддерживать все классы вне иерархии.
Нет такого "универсального интерфейса".

S> За подход без наследования.
Нет, я за подход без лишнего наследования.

S> Но она существует. Если у тебя нет то я только сочувствую тебе.
Жду убедительного примера.

S> Ну ты чего то автоматы пропустил. Я за автоматы на основе иерархии, ты за автоматы на уровне ветвлений.
Я не понимаю, о каких автоматах вы говорите, и не понимаю, зачем вы приписываете мне мнения, которых я не разделяю.

S> Да при чем тут учебники. Поверь я прекрасно вижу где ООП пригодно, а где оно не нужно, и где натянуто и буду брать более оптимальный вариант.
Либо вы плохо объясняете свою точку зрения, либо вы всё же заблуждаетесь. Потому что по вашим суждениям я пока не вижу, что вы правильно понимаете суть и область применения ООП.

Здравствуйте, Serginio1, Вы писали:
S> Это не прокрустово ложе, а вырождение. В той же природе у наследников могут вырождаться хвост, волосянной покров итд.
Природа тут ни при чём, прекратите писать чушь.
Какой смысл в этом вырождении? Зачем вы хотите иметь в сигнатуре класса атрибут, которого на самом деле нету?
Чтобы отложить обнаружение ошибки до рантайма и увеличить расходы на отладку?
Вся идея статической типизации — отлавливать такие ошибки на этапе компиляции.

S> Приходится либо полностью перепроводить по одному измененному регистру (в 8 ке это можно), либо оставлять по умолчанию. Либо начинать записывать с даты внесения этих реквизитов.
S>Вариантов куча.
И во всех этих вариантах внешний хелпер получается уместнее.

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

S>Здравствуйте, Serginio1, Вы писали:
S>> Это не прокрустово ложе, а вырождение. В той же природе у наследников могут вырождаться хвост, волосянной покров итд.
S>Природа тут ни при чём, прекратите писать чушь.
S>Какой смысл в этом вырождении? Зачем вы хотите иметь в сигнатуре класса атрибут, которого на самом деле нету?
S>Чтобы отложить обнаружение ошибки до рантайма и увеличить расходы на отладку?
S>Вся идея статической типизации — отлавливать такие ошибки на этапе компиляции.
А вот здесь проблема должна решаться через возможность удаления из видимости этого свойства. Перегружать (overload )через new можно, а удалять нельзя?

S>> Приходится либо полностью перепроводить по одному измененному регистру (в 8 ке это можно), либо оставлять по умолчанию. Либо начинать записывать с даты внесения этих реквизитов.
S>>Вариантов куча.
S>И во всех этих вариантах внешний хелпер получается уместнее.
А куда мне в этот хэлпер новое свойство то ввести?

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

S>> Да при чем тут учебники. Поверь я прекрасно вижу где ООП пригодно, а где оно не нужно, и где натянуто и буду брать более оптимальный вариант.
S>Либо вы плохо объясняете свою точку зрения, либо вы всё же заблуждаетесь. Потому что по вашим суждениям я пока не вижу, что вы правильно понимаете суть и область применения ООП.
В реальной жизни многие классы имеют множественное наследование, поэтому главное выбрать основного предка и правильно спроектировать иерархию.
Кстати не понимаю почему в Net нет такого понятия как Implements, когда за реализацию интерфейса отвечает конкретное поле. А так приходится городить интерфейсные методы и свойства на этом поле.
Или применять подход как запрос интерфейса у объекта. И вот он появился первый предок у которого есть понятие тип, вид, И метод или интерфейс с методом ДайкаМнеНужныйИнтерфейс()

Затем появляются абстрактные справочник,Документ, регистры. Регистры сведений тоже имею иерархию периодические непериодические.
А вот дальше сложнее. Нужно выделить частоиспользуемы, а значит и более затратные в алгоритмах. Например списание, перемещение, реализация имеют одинаковое свойство как списание с регистров товара.
С другой стороны Поступление оприходование и то же перемещение имеют свойство оприходования товара. Но при этом у них должны быть поля табличной части и документа одинаковыми для отражения их в регистрах учета.
И вот здесь можно выделить базового родителя у которого есть такие поля а от него уже отнаследовать документы для поступления и списания. Гермофродита типа перемещение нужно отрабатывать через интерфейс который будут поддерживать и наследники от поступления. Так при введении учета номенклатуры в разрезе ДопХарактеристик мне при всего лишь придется добавить эту ДопХарактеристику в базовый класс и изменить алгоритмы проведения.
Толи в хэлпере через интерфейс или в базовом классе на который будет и натянут интерфейс в базовом классе. Минимум движений.
А сейчас реально забываешь куда нужно добавлять, хотя если бы 1С была типизирована, то изменение интерфейса должно былобы вызвать ошибки об отсутствии их реализации. Но опять же это не панацея, но таких вещей полно.

Здравствуйте, Serginio1, Вы писали:
S>>Наследование нужно там, где нужен полиморфизм и возможность подстановки. В геометрии таких задач нет.
S> Почему?
Потому, что задача так устроена.
S>Вот Например
S>class Фигура()
S>Point [] массивТочек;
S>public Фигура(int[] массивТочек)
S>public void Начертить();
S>end;
Это понятно.

S>class треугольник:Фигура
S>public треугольник(Point a, Point b, Point c)
S>{
S> массивТочек=new Point[]{a,b,c}

S>}
S>void ПовернутьТреугольникНа90Градусов()
S>end
Это — нет.

S> Метод Начертить будет один для всех. А вот метод ПовернутьТреугольникНа90Градусов только для треугольника.
Почему нельзя повернуть на 90 градусов любую фигуру?
И ещё раз повторюсь: наследовать имеет смысл тогда, когда есть полиморфное поведение.
В вашем примере его нету — метод Начертить неполиморфен.

S> А какой ответ ты хочешь услышать? Для функциональности хэлпера я должен придоставить интерфейс со 100 свойствами.
Ответ на вот этот вопрос: зачем хэлперу все 100 свойств, если 97 из них — "дефолтные", т.е. он может прекрасно обойтись без них.

S>У меня есть 2 подхода либо реализовывать этот интерфейс внутри класса, либо создать класс поддерживающий этот интерфейс и заполнить только часть его полей (значительно меньшую) оставив остальные по умолчанию.
Подходов значительно больше, но выбрать верный основываясь на ваших отрывочных фразах невозможно.

S>>Ну это совсем другое. Посмотрите внутрь GetEnumerator для интереса.
S> Ну и например Энумераторы на основе поля в составе класса или куча yield, где генерятся классы обертки. Все то о чем я тебе и говорю.
Я не понимаю, о чём вы говорите. Впервые слышу о енумераторе на основе поля, а также о генерации классов-обёрток над кучей yield.
И тем более не понимаю, какое отношение всё это имеет к трансформаторам из int в double.

S>Кстати а с чего это ты на Вы перешел. Может и мне на Вы при общении с тобой перейти.
Мне так проще.

S> Стоп ты предлагаешь контракты не на уровне наследования а на уровне контракта ввиде Интерфейса.
Нет. Я предлагаю не заставлять класс выполнять те обязанности, которые может выполнить кто-то другой на основе его публичного интерфейса. К примеру, совершенно бессмысленно заставлять класс Фигура реализовывать метод Начертить, т.к. всё, что нужно Начертателю — это набор векторных примитивов, из которых состоит фигура.

S>Тот же самый интерфейс я могу реализовать в базовом классе, а в наследниках только перекрывать некоторые методы и свойства. В чем проблема?
В том, что вы не понимаете разницы в модальностях глаголов. "Я могу сделать" и "мне стоит сделать" семантически различны. Совершенно не обязательно делать всё, что возможно. К примеру, без потери семантики можно отказаться от всех скаляров в программе, и заменить их массивами длины 1.
Наследование — очень жёсткая зависимость. Его надо применять не там, где можно, а там, где без него нельзя.

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

S>>Я не понимаю, о каких автоматах вы говорите, и не понимаю, зачем вы приписываете мне мнения, которых я не разделяю.
S> Детеринированные конечные автоматы ДКА.
И с чего вы взяли, что я за ДКА на основе ветвлений?

Здравствуйте, Serginio1, Вы писали:
S>В реальной жизни многие классы имеют множественное наследование, поэтому главное выбрать основного предка и правильно спроектировать иерархию.
В реальной жизни никаких классов нет.
Классы — это наш способ моделировать реальность. И это — далеко не единственный способ. Посмотрите на javascript — он прекрасно обходится без классов, и многие аспекты реальных объектов его подход моделирует гораздо лучше.

S>Кстати не понимаю почему в Net нет такого понятия как Implements, когда за реализацию интерфейса отвечает конкретное поле. А так приходится городить интерфейсные методы и свойства на этом поле.
Потому что не стали усложнять платформу встроенной поддержкой агрегации. Она не так проста, как кажется.

S>Или применять подход как запрос интерфейса у объекта. И вот он появился первый предок у которого есть понятие тип, вид, И метод или интерфейс с методом ДайкаМнеНужныйИнтерфейс()
Запрос интерфейса у объекта в дотнете вполне себе есть. То, как он сделан в COM, который вас вдохновляет, напрямую связано с поддержкой агрегации. А её, в свою очередь, сделали потому, что наследования реализации в COM сделать не получилось.

S> Затем появляются абстрактные справочник,Документ, регистры. Регистры сведений тоже имею иерархию периодические непериодические.
S>А вот дальше сложнее. Нужно выделить частоиспользуемы, а значит и более затратные в алгоритмах. Например списание, перемещение, реализация имеют одинаковое свойство как списание с регистров товара.

S>С другой стороны Поступление оприходование и то же перемещение имеют свойство оприходования товара. Но при этом у них должны быть поля табличной части и документа одинаковыми для отражения их в регистрах учета.
S>И вот здесь можно выделить базового родителя у которого есть такие поля а от него уже отнаследовать документы для поступления и списания. Гермофродита типа перемещение нужно отрабатывать через интерфейс который будут поддерживать и наследники от поступления.
Ключевое заблуждение выделено. Вся проблема — в том, что никакого наследования "на самом деле" нет. Никто не заводит новый тип документа в бухгалтерии как "давайте отнаследуемся от накладной на поступление и перекроем кое-какие виртуальные методы". Просто есть некий workflow, есть нужные для него реквизиты, и есть документ с этими реквизитами. Это вы приходите со своим замыленным ООП взглядом и говорите "о! давайте отнаследуем всё от документа ХХХ".
А всё почему? Из-за непонимания ООП. ООП — оно целиком про поведение. Структура — вторична. Это очень частая ошибка — строить иерархию наследования исходя из имеющихся атрибутов. Именно это заблуждение побуждает наследовать прямоугольник от квадрата.
Надо строить иерархию, исходя из поведения.
Как только это становится понятным, сразу всё облегчается. У документов поведения, связанного со складом, нету вовсе. "Куда ведёт эта дорога? — Сколько я себя помню, эта дорога лежала себе там же, где и лежит". Документ всего лишь отражает некоторые факты, это и есть его обязанность. А принимать решения о корректировке складских остатков должен кто-то другой — тот, кто знает, чем LIFO отличается от FIFO, и каким образом хранится информация о партиях на складе.

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

E>Интересно, а из std::vector ты тоже выводишь наследникв "вектор из трёх элементов", "вектор из четырёх элементов" и т. д?..

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

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

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

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

S>Здравствуйте, Serginio1, Вы писали:
S>>В реальной жизни многие классы имеют множественное наследование, поэтому главное выбрать основного предка и правильно спроектировать иерархию.
S>В реальной жизни никаких классов нет.
S>Классы — это наш способ моделировать реальность. И это — далеко не единственный способ. Посмотрите на javascript — он прекрасно обходится без классов, и многие аспекты реальных объектов его подход моделирует гораздо лучше.
Ну мне ближе 1С там никаких классов нет. Одно процедурное программирование + модули обработки. Но вот всегда для решения множества задач необходимы классы, даже без иерархии но хотя бы с делегатами, которые в массе своей могут заменять перекрытие методов.

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

S>> Затем появляются абстрактные справочник,Документ, регистры. Регистры сведений тоже имею иерархию периодические непериодические.
S>>А вот дальше сложнее. Нужно выделить частоиспользуемы, а значит и более затратные в алгоритмах. Например списание, перемещение, реализация имеют одинаковое свойство как списание с регистров товара.

S>>С другой стороны Поступление оприходование и то же перемещение имеют свойство оприходования товара. Но при этом у них должны быть поля табличной части и документа одинаковыми для отражения их в регистрах учета.
S>>И вот здесь можно выделить базового родителя у которого есть такие поля а от него уже отнаследовать документы для поступления и списания. Гермофродита типа перемещение нужно отрабатывать через интерфейс который будут поддерживать и наследники от поступления.
S>Ключевое заблуждение выделено. Вся проблема — в том, что никакого наследования "на самом деле" нет. Никто не заводит новый тип документа в бухгалтерии как "давайте отнаследуемся от накладной на поступление и перекроем кое-какие виртуальные методы". Просто есть некий workflow, есть нужные для него реквизиты, и есть документ с этими реквизитами. Это вы приходите со своим замыленным ООП взглядом и говорите "о! давайте отнаследуем всё от документа ХХХ".
Ну вот я ничего в 1С не перекрываю. Горожу кучу копи пасте в пердопределенных методах. Нет строгости в наименованиии атрибутов, что приводит к сложности утинной типизации итд.

S>А всё почему? Из-за непонимания ООП. ООП — оно целиком про поведение. Структура — вторична. Это очень частая ошибка — строить иерархию наследования исходя из имеющихся атрибутов. Именно это заблуждение побуждает наследовать прямоугольник от квадрата.

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

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

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

Ну я уже упоминал тебе карты раскроя. Для каждого вида фигур можно сделать либо общий алгоримт перебора с поворотами на определенные углы. То для прямоугольников углы будут строго ограничены.
А для Окружности вообще нечего поворачивать.

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

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

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

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

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

Ну и есть алгоритмы, которые могут оперировать только с векторами определённой размерности. Векторное произведение, например...

Ты на вопрос-то ответишь?..

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

Типа ты себе мыслишь так, что метод GetArea() у полигона будет что-то там такое умное считать, а вот у его наследника треугольника будет считать по простой формуле?..

Ты уверен, что это будет более выгодно, чем просто написать

if( vertexCount == 3 ) {
    return calcTriangleArea( vertex[0], vertex[1], vertex[2] );
}

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

(x[i]-x[i+1])*(y[i]+y[i+1])/2

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

Так примеры того, зачем треугольник выводить из многоугольника будут?..

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

E>Кроме того, я сильно подозреваю, что обычный алгоритм суммирования по трапециям

(x[i]-x[i+1])*(y[i]+y[i+1])/2

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

E>Так примеры того, зачем треугольник выводить из многоугольника будут?..

Ну я уже упоминал тебе карты раскроя. Для каждого вида фигур можно сделать либо общий алгорить перебора с поворотами на определенные углы. Так если не брать структуру, то для прямоугольников углы будут строго ограничены и иметь 2 вида положения, для треугольников 4, для окружности 1.

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

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

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

А зачем периметр или площадь треугольника вычитать иным способом, чем периметр и площадь N-уголника?

Тебя же просят привести пример РЕАЛЬНОГО алгоритма, где это всё было бы востребовано?..

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

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

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

E>А зачем периметр или площадь треугольника вычитать иным способом, чем периметр и площадь N-уголника?

E>Тебя же просят привести пример РЕАЛЬНОГО алгоритма, где это всё было бы востребовано?..

А зачем тратить лишнее время. Сколько точек нужно для расчета периметра илм площади для окружности?

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

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

Почему наследование? Ты типа делаешь, кроме типа "фигура" ещё и тип "фигура в коробочке простой формы". Зачем вторая должна быть наслдником, а не агрегатором первой?

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

E>Тебя же просят привести пример РЕАЛЬНОГО алгоритма, где это всё было бы востребовано?..

Я уже приводил пример с картами раскроя. Так прямоугольный крой стоит дешевле чем криволинейный. Кроме того есть кромкование которое зависит от периметра.
Оптимальность раскроя зависит от общей площади деталей к площади листа. Ну и алгоритмы раскроя достаточно жадные до ресурсов и относятся к классу NP-полная задача

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

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

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

E>Почему наследование? Ты типа делаешь, кроме типа "фигура" ещё и тип "фигура в коробочке простой формы". Зачем вторая должна быть наслдником, а не агрегатором первой?

E>Мало того, "коробочка простой формы" тоже скорее всего не нуждается в том, что бы быть полиморфной...

Ну а доступ к этому агрегату то через интерфейс будешь городить? Какой смысл?
Про агрегаты я уже синклеру писал http://www.rsdn.ru/forum/philosophy/5119558.1

А чем плохо наследование, если оно реально присутствует и отвечает за частные случаи. То есть Квадрат это фигура состоящая из 4 точек итд?
В одних случаях хорошо оперировать как квадрат в других случаях как фигура. Так человек это млекопитающего и его внутренние органы соответствуют свинье итд.
При этом свинья выступает во многих случаях как моделью для изучения влияния различных воздействий.

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

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

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

А как делаешь ты? Вот, например, у тебя в качестве упрощённых фигур есть круг, треугольник, прямоугольник, квадрат и элипс. Как ты, например, проверяешь, что нет пересечений?

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

S> А зачем тратить лишнее время. Сколько точек нужно для расчета периметра илм площади для окружности?

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

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

S> А зачем тратить лишнее время. Сколько точек нужно для расчета периметра илм площади для окружности?

А ты окружность наследуешь из полигона с каким числом вершин, кстати?..

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

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

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

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

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

E>Я бы, вот, например, сделал бы сразу такое понятие, как "гипотеза размещения", которая содерала бы в себе поворот, сдвиг и упрощённый объемлющий полигон исходного полигона, при помощи которого можно быстро проверить что что полигоны не пересекаются, ну и сам исходный полигон или ссылку на него.
E>Потом по соображениям подобия там, или ещё каким-то эвристикам, строил бы по каждому полигону массив гипотез, а потом перебирал бы их как-то целенаправленно...

E>А как делаешь ты? Вот, например, у тебя в качестве упрощённых фигур есть круг, треугольник, прямоугольник, квадрат и элипс. Как ты, например, проверяешь, что нет пересечений?

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

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

S>Я уже приводил пример с картами раскроя. Так прямоугольный крой стоит дешевле чем криволинейный. Кроме того есть кромкование которое зависит от периметра.

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

Общая длина реза зависит от того, как много границ удаётся совместить с граиницами слэба или границами деталей, но как раз тут и НЕЛЬЗЯ приближать фигуру упрощённой формой.

Общая длина кромкования вообще зависит только от самих деталей

S>Оптимальность раскроя зависит от общей площади деталей к площади листа.
Забыл ещё возможность переиспользования реза. То есть что бы один рез разделял соразу две детали.

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

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

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

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

S>> А зачем тратить лишнее время. Сколько точек нужно для расчета периметра илм площади для окружности?

E>Если ты хранишь окружность, как дугу кривой какого-то семейства, то три-четыре, в зависимости от того, какое семейство кривых...

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

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

S> Ну а доступ к этому агрегату то через интерфейс будешь городить? Какой смысл?
Зачем? Просто структура из нескольких поелй и всё...

S>Про агрегаты я уже синклеру писал http://www.rsdn.ru/forum/philosophy/5119558.1
Я ничего не понял в том твоём сообщении...

S>А чем плохо наследование, если оно реально присутствует и отвечает за частные случаи. То есть Квадрат это фигура состоящая из 4 точек итд?
1) Я не понимаю, что значит "реально присутствует"
2) Наследование плохо тем, что накладывает связь и граничения. Если эта связь и ограничения не нужны для алгоритмов, то это недостаток.
Ты можешь обхяснить, почему наследование, а не агрегирование?
3) Логика "квадарт -- наследник фигуры из 4-х точек" вообще ущербна в большинстве задач. И она ничем не оличается от логики "4-вектор -- это std::вектор из 4-х элементов"
Ты так и не ответил создаёшь ли ты наследников вектора определённых размерностей?..

если нет, то почему?

S> В одних случаях хорошо оперировать как квадрат в других случаях как фигура. Так человек это млекопитающего и его внутренние органы соответствуют свинье итд.
Ну примеры-то *одних случаев* будут?..

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

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

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

S>> А зачем тратить лишнее время. Сколько точек нужно для расчета периметра илм площади для окружности?

E>Если ты хранишь окружность, как дугу кривой какого-то семейства, то три-четыре, в зависимости от того, какое семейство кривых...

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

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

E>>Почему наследование? Ты типа делаешь, кроме типа "фигура" ещё и тип "фигура в коробочке простой формы". Зачем вторая должна быть наслдником, а не агрегатором первой?

Я утверждаю, что если даже где-то нужен именно квадрат, то это должен быть ДРУГОЙ класс, который, например, может построить фигуру, если она кому-то понадобится...

Но и сам по себе класс "квадраты" для меня довольно таки сомнителен в геометрических задачах...

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

Но задач, где такие сущности нужны я не знаю

S>А может они введены для упрощения многих алгоритмов, в том числе и для базовых (тригонометрия например)

Примеры многих базовых алгоритмов таки будут?

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

E>>А как делаешь ты? Вот, например, у тебя в качестве упрощённых фигур есть круг, треугольник, прямоугольник, квадрат и элипс. Как ты, например, проверяешь, что нет пересечений?

S> Я возьму и приведу их всех к вписанному прямоугольнику.

К вписанному или к описанному?
Что такое "вписанный прямоугольник" для окружности, например? В смысле который из?
Что такое для треугольника?

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

А зачем тогда вообще эти промежуточные упрощённые фигуры?

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

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

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

S>>Я уже приводил пример с картами раскроя. Так прямоугольный крой стоит дешевле чем криволинейный. Кроме того есть кромкование которое зависит от периметра.

E>Ничего не понимаю. Кривой у теюя там крой или прямой зависит от самих по себе фигур,а не от карты.

Я тебе привел пример для чего нужны площадь и периметр.

E>Общая длина реза зависит от того, как много границ удаётся совместить с граиницами слэба или границами деталей, но как раз тут и НЕЛЬЗЯ приближать фигуру упрощённой формой.

Почему? На практике так и происходит, так как проще оперировать простыми фигурами.

E>Общая длина кромкования вообще зависит только от самих деталей

Нужен периметр.

S>>Оптимальность раскроя зависит от общей площади деталей к площади листа.
E>Забыл ещё возможность переиспользования реза. То есть что бы один рез разделял соразу две детали.

S>>Ну и алгоритмы раскроя достаточно жадные до ресурсов и относятся к классу NP-полная задача
E>Ну они же жадные в области перебора вариантов размещения деталей, а не в области обсчёта конкретного варианта. Конечно детали можно для кроя немного упростить. Ну там совсем кривые края спрямить с запасом, и пометить, что переиспользование этой границы не является выигрышем, убрать с деталей всякие пазы щели и дырки, и т. д. Но в целом вычислить размещение реального полигона или упрощённого -- это разница всего-то в разы. Не в разы разница -- это структура перебора вариантов. Её-то и надо оптимизировать, а не фигню.

Ну так этих вариантов тем больше, чем более сложные фигуры.

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

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

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

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

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

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

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

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

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

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

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

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

S>> Ну а доступ к этому агрегату то через интерфейс будешь городить? Какой смысл?
E>Зачем? Просто структура из нескольких поелй и всё...

S>>Про агрегаты я уже синклеру писал http://www.rsdn.ru/forum/philosophy/5119558.1
E>Я ничего не понял в том твоём сообщении...

Если нет иерархии, а ты хочешь работать как с фигурой тебе нужно выставлять наружу что то, к чему ты можешь обратиться.
Одно дело, что ты работаешь только с одной фигурой то твой подход хорошь, если уже с несколькими, то нужно определять тип и тд. Как это делается в 1С.

S>>А чем плохо наследование, если оно реально присутствует и отвечает за частные случаи. То есть Квадрат это фигура состоящая из 4 точек итд?
E>1) Я не понимаю, что значит "реально присутствует"
E>2) Наследование плохо тем, что накладывает связь и граничения. Если эта связь и ограничения не нужны для алгоритмов, то это недостаток.
E>Ты можешь обхяснить, почему наследование, а не агрегирование?
E>3) Логика "квадарт -- наследник фигуры из 4-х точек" вообще ущербна в большинстве задач. И она ничем не оличается от логики "4-вектор -- это std::вектор из 4-х элементов"
E>Ты так и не ответил создаёшь ли ты наследников вектора определённых размерностей?..

E>если нет, то почему?

Я уже кучу примеров написал. Думаю, что дальше уже бессмысленно что то говорить.
S>> В одних случаях хорошо оперировать как квадрат в других случаях как фигура. Так человек это млекопитающего и его внутренние органы соответствуют свинье итд.
E>Ну примеры-то *одних случаев* будут?..

Я уже тебе их кучу привел.

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

Ну так шимпанзе то мало, а коров и свиней полно.

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

S> Я тебе привел пример для чего нужны площадь и периметр.
Да площадь и периметр могут и просто так заинтересовать. Не важно. Важно то, что их вычисление во время поиска оптимального раскроя не требуется...

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

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

S>Нужен периметр.
И что, это какая-то сложная задача, что ли? Зачем периметр треугольника или даже окружности, считать как-то иначе, чем периметр n-угольника?

E>>Не в разы разница -- это структура перебора вариантов. Её-то и надо оптимизировать, а не фигню.

S> Ну так этих вариантов тем больше, чем более сложные фигуры.

Именно поэтому надо задавать целенаправленность и отсечения в перебор вариантов, а не заниматься ерёндой с ООп-представлением фигур

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

IMHO, Это говорит, что твоя прекрасная ООП-программа просто не работает. Долго и вычурно вычисляет не то...

Сравни с оптимизирующим компилятором С++, например. За ним вручную не особо пооптимизируешь, в отличии от. Только не надо говорить, что задача кроя проще, чем задача оптимизации С++

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

S> Если нет иерархии, а ты хочешь работать как с фигурой тебе нужно выставлять наружу что то, к чему ты можешь обратиться.
S>Одно дело, что ты работаешь только с одной фигурой то твой подход хорошь, если уже с несколькими, то нужно определять тип и тд. Как это делается в 1С.
Зачем это всё? Ты просто НУЖНЫЕ для перебора данные предоставь и всё. На кой для перебора вариантов кроя тип фигуры?

Я тут где-то тебе писал, как бы я сделал. С гипотезами размещения, генерируемыми по полигонам. Ты присмотрись к такой конструкции, она прямая, удобная и простая. И скорее всего после такой программы дооптимизировать вручную не получится, кстати

E>>Ты можешь обхяснить, почему наследование, а не агрегирование?
E>>3) Логика "квадарт -- наследник фигуры из 4-х точек" вообще ущербна в большинстве задач. И она ничем не оличается от логики "4-вектор -- это std::вектор из 4-х элементов"
E>>Ты так и не ответил создаёшь ли ты наследников вектора определённых размерностей?..

E>>если нет, то почему?

S> Я уже кучу примеров написал.
Ты не привёл пока ни одного КОНКРЕТНОГО примера алгоритма...

S>Думаю, что дальше уже бессмысленно что то говорить.
Ну ты на вопросы-то ответь?
а) Почему наследование, а не агрегирование?
б) Ты таки наследуешь из вектора 3-вектор, 4-вектор и т. д.?
б') Если таки нет, то почему?

E>>Ну примеры-то *одних случаев* будут?..

S> Я уже тебе их кучу привел.
Пока что ты привёл ровно один пример -- какой-то запутанный и неконкретный алгоритм оптимизации кроя, который, как потом ты сам же и написал, по факту ещё и не работает

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

S> Ну так шимпанзе то мало, а коров и свиней полно.
Не совсем уловил, какое влияние на ответ "насколько печень Х похожа на печень человека?" зависит от численности Х?

В конце концов макак просто как грязи, и они намного ближе к человеку, чем свиньи. И, тем не менее...

В общем предлагаю это "свинское" направление обсуждения не развивать. Оно толкьо дополнительно иллюстрирует, что ООП в жизни реально нифига не присутствует. Но это и так, IMHO, понятно

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

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

E>>>Почему наследование? Ты типа делаешь, кроме типа "фигура" ещё и тип "фигура в коробочке простой формы". Зачем вторая должна быть наслдником, а не агрегатором первой?

E>Я утверждаю, что если даже где-то нужен именно квадрат, то это должен быть ДРУГОЙ класс, который, например, может построить фигуру, если она кому-то понадобится...

E>Но и сам по себе класс "квадраты" для меня довольно таки сомнителен в геометрических задачах...

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

E>Но задач, где такие сущности нужны я не знаю

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

S>>А может они введены для упрощения многих алгоритмов, в том числе и для базовых (тригонометрия например)

E>Примеры многих базовых алгоритмов таки будут?
синус косинус итд. Я же написал тригонометрия. Числовые методы интегрирования итд.

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

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

E>>>А как делаешь ты? Вот, например, у тебя в качестве упрощённых фигур есть круг, треугольник, прямоугольник, квадрат и элипс. Как ты, например, проверяешь, что нет пересечений?

S>> Я возьму и приведу их всех к вписанному прямоугольнику.

E>К вписанному или к описанному?
E>Что такое "вписанный прямоугольник" для окружности, например? В смысле который из?
E>Что такое для треугольника?

Вписанный в прямоугольник. Так и знал, что докапаешься. Это минимальное соотношение площади фигуры к площади прямоугольника.

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

E>А зачем тогда вообще эти промежуточные упрощённые фигуры?

E>Сразу всё приводи к прямоугольникам и по ним проверяй грубо, а потом сразу по полигонам негрубо. Работать будет не сильно дольше, но сильно точнее. Раскрои будут оптимальнее...

А зачем алгоритмы с погрешностями, от большей к меньшей? Яркий пример метод половинного деления. Просто для уменьшения количества затрачиваемого времени.
Еще раз я уже писал тебе про NP полную задачу. Предлагаю тебе двинуть в эту область одна из таких программ K3.

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

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

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

E>Ну один там радиус или три точки -- разница не велика, в отличии от накладных расходов на организацию всего этого полиморфизма...

Для криволинеек там отнюдь не 3 точки.
А какие там расходы? В написании слова override?

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

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

Зачем всё это усложнение?
У тебя есть две сущности.
1) фигура
2) Вариант её размещения в раскрое.
Почему ты хочешь связать эти сущности отношением наследования?

Зачем? В какой момент и для какой операци тебе хочется работать с вариантом размещения, как с фигурой?

E>>Примеры многих базовых алгоритмов таки будут?
S>синус косинус итд. Я же написал тригонометрия. Числовые методы интегрирования итд.

Не понимаю, что такое синус окружности, например? Или n-угольника?

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

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

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

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

S>>Которая является фигурой и которую можно выразить через массив точек с определенным шагом.
E>Если всё можно приблизить тупо ломанными, то получаем просто массив границ отрезков, без дуг и криволинейностей. То есть примерно то же, тольео формулы чуть проще...

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

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

S> А какие там расходы? В написании слова override?
Больше кода, данных, сами данные сложнее, сложнее тестирование и т. д...

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

S> Вот наконец то.
Что "наконец-то"?
E>>Зачем из этой структуры выводить круги или квадраты я не понимаю.
S> А затем, что оперировать для алгоритмов проще простыми фигурами. Вспомни замечательные пределы?
Кому проще? И для каких алгоритмов?
Конкретка-то будет?

S> Ну наконец то. А вот с дугами то проще. Я особо не вникаю, но некоторые аппараты для резки оперировали только дугами, хотя проще для описания сплайны

Ты понимаешь, что дуги от отрезком вообще почти ничем не отличаются? Ну дял отрезка надо две точки знать, а для дуги там три или чеытре. Дальше всё ТАК ЖЕ.

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

Но ты говорил не о ДУГАХ/ОТРЕЗКАХ, а о полиморфных ФИГУРАХ. И пока что так ничего внятного про то, зачем тебе выводить из фигуры вообще, УЖЕ СОДЕРЖАЩЕЙ массив дуг, конкреетные фигуры, так рассказать и не смог.

Ты можешь какой-то код написать, который это ООП использует, например?

только РЕАЛЬНЫЙ, который какую-топ понятную задачу решает, а не "работает с фигурами вообще"...

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

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

S>> Если нет иерархии, а ты хочешь работать как с фигурой тебе нужно выставлять наружу что то, к чему ты можешь обратиться.
S>>Одно дело, что ты работаешь только с одной фигурой то твой подход хорошь, если уже с несколькими, то нужно определять тип и тд. Как это делается в 1С.
E>Зачем это всё? Ты просто НУЖНЫЕ для перебора данные предоставь и всё. На кой для перебора вариантов кроя тип фигуры?

E>Я тут где-то тебе писал, как бы я сделал. С гипотезами размещения, генерируемыми по полигонам. Ты присмотрись к такой конструкции, она прямая, удобная и простая. И скорее всего после такой программы дооптимизировать вручную не получится, кстати

Тебе осталось только на этом денежки заработать. Ты никак не понимаешь смысл NP полноты задачи. Сколько вариантов у 50 разных деталей на листе?

E>>>Ты можешь обхяснить, почему наследование, а не агрегирование?
E>>>3) Логика "квадарт -- наследник фигуры из 4-х точек" вообще ущербна в большинстве задач. И она ничем не оличается от логики "4-вектор -- это std::вектор из 4-х элементов"
E>>>Ты так и не ответил создаёшь ли ты наследников вектора определённых размерностей?..

E>>>если нет, то почему?

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

S>> Я уже кучу примеров написал.
E>Ты не привёл пока ни одного КОНКРЕТНОГО примера алгоритма...

То есть вычисление периметра и площади окружности для тебя недостаточно? Почему для вычисления площади ты использушь соответствующие формулы, а не как n вектор?

S>>Думаю, что дальше уже бессмысленно что то говорить.
E>Ну ты на вопросы-то ответь?
E>а) Почему наследование, а не агрегирование?
E>б) Ты таки наследуешь из вектора 3-вектор, 4-вектор и т. д.?
E>б') Если таки нет, то почему?

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

E>>>Ну примеры-то *одних случаев* будут?..

S>> Я уже тебе их кучу привел.
E>Пока что ты привёл ровно один пример -- какой-то запутанный и неконкретный алгоритм оптимизации кроя, который, как потом ты сам же и написал, по факту ещё и не работает

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

Почему нельзя? Можно так и так. Просто некоторые станки работают только с массивом точек. Только с дугами. А некоторые и так и сяк. Окражности да, криволинейки нет.

S>> Ну так шимпанзе то мало, а коров и свиней полно.
E>Не совсем уловил, какое влияние на ответ "насколько печень Х похожа на печень человека?" зависит от численности Х?

E>В конце концов макак просто как грязи, и они намного ближе к человеку, чем свиньи. И, тем не менее...

E>В общем предлагаю это "свинское" направление обсуждения не развивать. Оно толкьо дополнительно иллюстрирует, что ООП в жизни реально нифига не присутствует. Но это и так, IMHO, понятно

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

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

S> У тебя ничего нет сложного. Для вычисления площади окружности достаточно всего одного радиуса, для вычисления площади квадрата достаточно одной стороны.

Это просто не правда. Нужно не только сторону знать, но и тот факт,ч то это квадарт. А вот это уже может легко оказаться дороже, чем просто прожевать массив точек по формуле.
Особенно, если ты считаешь на какой-то суперпараллельной архитерктуре. Скажем на граф-карточке

E>>IMHO, Это говорит, что твоя прекрасная ООП-программа просто не работает. Долго и вычурно вычисляет не то...

S> Это не моя. Это K3.
"Твоя" в смысле "о которой ты писал". Если ты не имеешь отношения к её разработке, с чего ты взял, что там внутри такое странное ООП?

Ну и потом, похоже, там основное направление -- 3д можели всякие, визуализация, работа с ЧПУ и т. д. Оптимизация раскроя там просток ак-то написана. Не факт, что там хотя бы один нормальный математик в RnD есть, а не одни спецы по 3Д-моделям, как на сайте написано

S>Еще раз напомню класс задач NP полный. Как только ты прикинешь количество вариантов расположения 50 разных деталей на листе то все станет предельно ясно.
Слушай, я профессионально в AI математиком работаю. Я всё понимаю и говорю тебе, что не то они в совём Нижнем Новгороде делают.
В смысле то, конечно, так как им оптимальнй крой вообще не нужен. Им нужем минимально приемлемый. И то они не справляются, так как люди могут улучшить. Но и так сходит. Потому, что они продают не оптимизацию кроя, а автоматизацию бизнеса.

Впрочем, если тут есть люди из ЦИП "ГеоС", то можно было бы с ними обсудить что и как они делают почему и зачем и насколько хорошо выходит.
но я так думаю, что они под подпиской о неразглашении сидят, так что обсудить, даже если захотят, смогут сильно ограниченно

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

S> Тебе осталось только на этом денежки заработать.
не особо понятно как...

S> Ты никак не понимаешь смысл NP полноты задачи. Сколько вариантов у 50 разных деталей на листе?
А что, у 50 аппроксимированных кругами и сапогами деталей вариантов меньше что ли?..

Какой вообще выигрыш в структуре перебора ты получаешь за счёт всей этой ООП иерархии-то?

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

S> То есть вычисление периметра и площади окружности для тебя недостаточно? Почему для вычисления площади ты использушь соответствующие формулы, а не как n вектор?

Я вот не понимаю, ты говоришь об отрезках прямой или о кривых дугах? Если второе, то каких конкретно? (из какого семейства?)

просто ответ на твой вопрос зависит от того, что и с чем ты сравниваешь.
В частности, если ты сравниваешь n-угольник, с окружностью, то ответь мне на вопрос. При каком n уже можно выводить из n-угольника окружность?..

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

Хорошо. Это зафиксируем. И зачем тогда тебе специальный код для окружностей? по идее площадь трапеции под дугой и длину дуги тебе всё равно надо вычислять уметь, окружность, в зависимости от семейства, у тебя, скорее всего задаётся двумя дугами или одной. И зачем ради замены одной формулы на другую мутить ООП?

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

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

S>Классы — это наш способ моделировать реальность. И это — далеко не единственный способ. Посмотрите на javascript — он прекрасно обходится без классов, и многие аспекты реальных объектов его подход моделирует гораздо лучше.

Не заметно. Чуть не все фремворки используют классы на уровне библиотеки.

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

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

E>У тебя сколько фигур в типичном раскрое? штуки? Десятки? Сотни?..

Десятки около сотни.
S>> Еще раз я уже писал тебе про NP полную задачу. Предлагаю тебе двинуть в эту область одна из таких программ K3.

E>Спасибо, но я пока двигаю свою. Пока что наша группа лидирует...

E>Кстати, думаешь задача потимизации С++ не NP-полна что ли? Тем не менее обогнать оптимизатор С++ трудно, а ту программу в которой якобы есть все эти иерархии, как ты утверждаешь, таки можно, опять же, как ты утверждаешь...

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

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

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

S>> Вот наконец то.
E>Что "наконец-то"?
E>>>Зачем из этой структуры выводить круги или квадраты я не понимаю.
S>> А затем, что оперировать для алгоритмов проще простыми фигурами. Вспомни замечательные пределы?
E>Кому проще? И для каких алгоритмов?
E>Конкретка-то будет?
Еще раз повторю, для расположения фигур на листе.
S>> Ну наконец то. А вот с дугами то проще. Я особо не вникаю, но некоторые аппараты для резки оперировали только дугами, хотя проще для описания сплайны

E>Ты понимаешь, что дуги от отрезком вообще почти ничем не отличаются? Ну дял отрезка надо две точки знать, а для дуги там три или чеытре. Дальше всё ТАК ЖЕ.

Дуга окружности отличается от произвольной кривой.

E>При этом сами дуги тоже скорее всего не нужны полиморфные, хотя это вопрос простой оптимизации довольно.

E>Но ты говорил не о ДУГАХ/ОТРЕЗКАХ, а о полиморфных ФИГУРАХ. И пока что так ничего внятного про то, зачем тебе выводить из фигуры вообще, УЖЕ СОДЕРЖАЩЕЙ массив дуг, конкреетные фигуры, так рассказать и не смог.

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

E>Ты можешь какой-то код написать, который это ООП использует, например?

E>только РЕАЛЬНЫЙ, который какую-топ понятную задачу решает, а не "работает с фигурами вообще"...

Это от алгоритмов зависит. А чем проблемы раскроя не топ задача? Почему прямоугольник или прямоугольный треугольник не является наследником фигуры с массивом точек?

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

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

S>> У тебя ничего нет сложного. Для вычисления площади окружности достаточно всего одного радиуса, для вычисления площади квадрата достаточно одной стороны.

E>Это просто не правда. Нужно не только сторону знать, но и тот факт,ч то это квадарт. А вот это уже может легко оказаться дороже, чем просто прожевать массив точек по формуле.
E>Особенно, если ты считаешь на какой-то суперпараллельной архитерктуре. Скажем на граф-карточке

Для вычисления площади достаточно просто переопределить метод получения площади.

E>>>IMHO, Это говорит, что твоя прекрасная ООП-программа просто не работает. Долго и вычурно вычисляет не то...

S>> Это не моя. Это K3.
E>"Твоя" в смысле "о которой ты писал". Если ты не имеешь отношения к её разработке, с чего ты взял, что там внутри такое странное ООП?

E>Ну и потом, похоже, там основное направление -- 3д можели всякие, визуализация, работа с ЧПУ и т. д. Оптимизация раскроя там просток ак-то написана. Не факт, что там хотя бы один нормальный математик в RnD есть, а не одни спецы по 3Д-моделям, как на сайте написано

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

S>>Еще раз напомню класс задач NP полный. Как только ты прикинешь количество вариантов расположения 50 разных деталей на листе то все станет предельно ясно.
E>Слушай, я профессионально в AI математиком работаю. Я всё понимаю и говорю тебе, что не то они в совём Нижнем Новгороде делают.
E>В смысле то, конечно, так как им оптимальнй крой вообще не нужен. Им нужем минимально приемлемый. И то они не справляются, так как люди могут улучшить. Но и так сходит. Потому, что они продают не оптимизацию кроя, а автоматизацию бизнеса.

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

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

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

S>> Тебе осталось только на этом денежки заработать.
E>не особо понятно как...

S>> Ты никак не понимаешь смысл NP полноты задачи. Сколько вариантов у 50 разных деталей на листе?
E>А что, у 50 аппроксимированных кругами и сапогами деталей вариантов меньше что ли?..

E>Какой вообще выигрыш в структуре перебора ты получаешь за счёт всей этой ООП иерархии-то?

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

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

S>> То есть вычисление периметра и площади окружности для тебя недостаточно? Почему для вычисления площади ты использушь соответствующие формулы, а не как n вектор?

E>Я вот не понимаю, ты говоришь об отрезках прямой или о кривых дугах? Если второе, то каких конкретно? (из какого семейства?)

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

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

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

E>просто ответ на твой вопрос зависит от того, что и с чем ты сравниваешь.
E>В частности, если ты сравниваешь n-угольник, с окружностью, то ответь мне на вопрос. При каком n уже можно выводить из n-угольника окружность?..

Какая погрешность при соединении этих точек тебя устраивает? \lim_{x \to 0}\frac{\sin x}{x} = 1.

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

E>Хорошо. Это зафиксируем. И зачем тогда тебе специальный код для окружностей? по идее площадь трапеции под дугой и длину дуги тебе всё равно надо вычислять уметь, окружность, в зависимости от семейства, у тебя, скорее всего задаётся двумя дугами или одной. И зачем ради замены одной формулы на другую мутить ООП?

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

S>> Почему нельзя? Можно так и так. Просто некоторые станки работают только с массивом точек. Только с дугами. А некоторые и так и сяк. Окражности да, криволинейки нет.
E>В смысле? Не все фигуры можно вырезать на "некотрых станках" что ли? Или что?
E>Как вообще задача оптимального раскроя листа связана с форматом того данных для станка?

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

S>>>>синус косинус итд. Я же написал тригонометрия. Числовые методы интегрирования итд.
E>>>Не понимаю, что такое синус окружности, например? Или n-угольника?

S>>Замечательный предел помнишь? И как расчитать площадь n угольника?

E>Если у теюя n-угольник задан КООРДИНАТАМИ своих вершин (у тебя же так задан, я надеюсь?), то что бы рассчитать его площадь надо просто просумировать по кругу (x[i]-x[i+1])*(y[i] + y[i+1]) и разделить результат на
2. (Тут предполагается, что после последнего индекса +1 переходит снова к первому)
А теперь периметр посчитай.

E>Правда площадь получится со знаком, который зависит в каком направлении описывался n-угольник. Но знак легко отбросить.
E>Этот метод быстрый, так как содержит всего-то 3N сложений и N умножений (ну и в конце надо ещё на 2 поделить, правда). При этом, если исходные данные целые, то и все промежуточные ТОЖЕ, так что он ещё всё вычисляет ТОЧНО, то есть вообще без погрешностей.
Особенно это правильно делать для окружностей где достаточно хранить радиус. Для прямоугольника достаточно хранить две стороны.

E>если же считать площадь по 3-ка по формуле Герона, а не по этой общей, то надо сначала вычислить три длины стороны (это уже куча умножений, сложений и три корня квадратных в конце), и эти все вычисления уже в плавучке и с погрешностями.
E>Потом эти длины сторон надо будет складывать и перемножать, а из результата извлекать корень. Можно пояснить на кой это вс делать?

Для треуголька, прямоугольника проще оперировать сторонами. И поворачивать их на 10% в раскрое не имеет смысла.

E>Это типа первоапрельская шутка такая что ли?..

Ладно. Извини. Я на этом прекращу. А то это бесконечный разговор.

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

E>>Это просто не правда. Нужно не только сторону знать, но и тот факт,ч то это квадарт. А вот это уже может легко оказаться дороже, чем просто прожевать массив точек по формуле.
E>>Особенно, если ты считаешь на какой-то суперпараллельной архитерктуре. Скажем на граф-карточке

S> Для вычисления площади достаточно просто переопределить метод получения площади.
Это исключит счёт на карточке, например...

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

S> Да и нейдобно обращаться через лишнюю точку.
А не надо через чтоку, лучше специальный метод для доступа иметь.

Зато читабельнее и код лучше структурируется.

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

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

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

S>> Да и нейдобно обращаться через лишнюю точку.
E>А не надо через чтоку, лучше специальный метод для доступа иметь.

E>Зато читабельнее и код лучше структурируется.
Я это и предлагал в разговоре с синклером. Где класс можно рассматрвать как свойсва виртуальных свойств как отдельно так и полностью.
Просто иногда некоторые свойства агрегатов перекрываются , но по сути имет одно и тот же смысл.
Понятно, что большая часть таких решений реализуется через интерфйсы, но можно напрмер сделать класс обертку который будет дергать нужные свойства например через делегаты, что бы не переопределять для всех свою реализацию.

Но по сути это тоже вариант наследования.

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

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

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

S> Ну мне ближе 1С там никаких классов нет. Одно процедурное программирование + модули обработки. Но вот всегда для решения множества задач необходимы классы, даже без иерархии но хотя бы с делегатами, которые в массе своей могут заменять перекрытие методов.
Вы только что смешали в одну кучу две существенно различные парадигмы, если что.

S>>Запрос интерфейса у объекта в дотнете вполне себе есть. То, как он сделан в COM, который вас вдохновляет, напрямую связано с поддержкой агрегации. А её, в свою очередь, сделали потому, что наследования реализации в COM сделать не получилось.
S> Нет не так как в ком. Смотри выше.
Что значит "нет"? Вы опять лезете в ненужные подробности. В дотнете запрос интерфейса сделан через приведение типа. А в COM — через специальный метод.
Сделано это потому, что в COM нельзя было полагаться на реализацию наследования, как в гомогенной архитектуре типа С++ или .Net. Вместо наследования в COM ввели агрегацию — а про неё знает только участник агрегата, исполняющая среда не может самостоятельно выполнить приведение. Вот и приходится делегировать работу по тайп-касту методу QueryInterface, который обязан реализовывать сам объект.

S>>Ключевое заблуждение выделено. Вся проблема — в том, что никакого наследования "на самом деле" нет. Никто не заводит новый тип документа в бухгалтерии как "давайте отнаследуемся от накладной на поступление и перекроем кое-какие виртуальные методы". Просто есть некий workflow, есть нужные для него реквизиты, и есть документ с этими реквизитами. Это вы приходите со своим замыленным ООП взглядом и говорите "о! давайте отнаследуем всё от документа ХХХ".
S> Ну вот я ничего в 1С не перекрываю. Горожу кучу копи пасте в пердопределенных методах. Нет строгости в наименованиии атрибутов, что приводит к сложности утинной типизации итд.
Зачем copy-paste? Я плохо знаком с 1С, наверное чего-то не понимаю.

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

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

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

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

Здравствуйте, Serginio1, Вы писали:
S> Еще раз любая частная фигура есть потомок общей фигуры. Можно любую фигуру привести к частной как вписанную.
Всё строго наоборот. Вот у нас есть метод BoundingRect GetBoundingRect(Polygon p), который для любой фигуры строит вмещающий её прямоугольник.
Для всего набора фигур строим такие прямоугольники, и размещаем уже их. Получаем некий раскрой, оцениваем его оптимальность.
Можем сразу оценить перспективность раскроя, оценив соотношение площади исходной фигуры к вмещающему прямоугольнику.
Мы можем выбрать один из примитивов, на который исходная фигура наиболее похожа — опять же пройдясь по списку методов GetBoundingXXX и сравнив площади.
И так далее.

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

S> У документов поведения, связанного со складом, нету вовсе.

из того, что у документа нет поведения связанного со складом, совсем не вытекает, что у документа должны отсутствовать методы, связанные со складов.

В качестве примера, можно взять gdocs — у документа есть метод Download as. Само же поведение вызываемое этим методом находится не в документе, документ является лишь проксей.

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

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

Тоже не понятно чем специальная формула для треугольника будет лучше...

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

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

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

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

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

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

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

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

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

Здравствуйте, 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!

Здравствуйте, 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 точек". Вы же не думаете, что периметр трапеции вычисляется как-то иначе, чем периметр прямоугольника?
Зачем вообще вводить лишнюю сущность как фигура из трех сторон? Зачем вводить замечательные пределы итд?

Здравствуйте, 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 позволяет выполнять бесконфликтную агрегацию. Агрегация — это концепция СОМ, отвечающая за комбинацию нескольких классов для выполнения одной задачи. Другое немаловажное преимущество применения директивы

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

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

Здравствуйте, 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 и проблема решена. Нужна конверсия одной фигуры в другую ? Адаптер вам поможет.
Я уже это объясняю неделю. Но здесь упирается в то что так оно вроде и есть, а дай конкретную реализацию. И зачем разные фигуры если достаточно одной. Итд.

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

Здравствуйте, 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>В большинстве случаев достаточно и фигуры ввиде массива точек, и вида соединения между точек прямолинейное или криволинейное.
Вы практически цитируете меня.

Здравствуйте, 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 };

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

S> То есть все частные формы фигур не нужны?
Что значит "фигуры"? Как типы не нужны. Во всяком случае в задаче оптимизации раскроя.

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

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

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

S> Исходя из тех же степеней свободы.
Каких степеней свободы?

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

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

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

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

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

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

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

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

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

S> Нет оригинальная фигура если ты её не впишешь в прямоугольник для оптимального расположения нужно выбрать положение от крайних фигур.
Почему и кому это "нужно"?

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

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

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

E>>Правда конкретно у портных вертеть фигуры НЕЛЬЗЯ.

S> Почему, если не зависит от структуры Кожи или других материалов? Так скажем не портных а раскройщиков одежды.

Потому, что портные шьют из ткани, а её механические свойства анизотропны... (Свойства в направлении утка и основы сильно отличаются)...

IMHO, это тут офтоп.

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

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

У термина "ООП" есть устоявшееся значение. Если хочешь, что бы тебя понимали, не стоит толковать его расширительно или нетрадиционно...

S>class треугольник:Фигура
S>public треугольник(Point a, Point b, Point c)
S>{
S> массивТочек=new Point[]{a,b,c}

S>}
S>void ПовернутьТреугольникНа90Градусов()
S>end

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

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

Здравствуйте, Abyx, Вы писали:
A>в первую очередь контракты и требования не должны быть контр-интуитивными.
От щас прям. В первую очередь контракт должен удовлетворять требованиям. Интуитивная понятность тут малоприменима.
A>если есть объект Квадрат, то его площадь должна быть равна квадрату стороны. Иначе он не может называться "Квадрат".
Я вам уже сказал: в случае таких требований вы должны отказаться от полиморфизма.

A>если есть метод add(a, b), то в его реализацией не может быть { return a — b };
А что ваша интуиция говорит по поводу метода multiply(a, b)? Должен ли он возвращать то же, что и multiply(b, a)?

Здравствуйте, Sinclair, Вы писали:
S>>У прямоугольника будет 4.
S>У прямоугольника — ~~две~~ степени свободы; при этом одна из них дискретная.
опечатка: три

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

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

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

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

С примитивами проще работать чем с оргигиналами. http://lemarse.spb.ru/products/cut_leather/

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

Для максимального использования площамди материала.
E>Смотри, если я решаю, что эту фигуру надо вписать в прямоугольник и дальше прямо вот как прямоугольник и размещать, то это, на самом деле означает, что я всего-то фиксирую углы поворота этой фигуры, котрые стоит попробовать. Конкретно 90 о 0 градусов. И ВСЁ, боьше это ничего не значит.

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

Угу то есть треугольник к прямоуголик можно пристраивать углом к стороне прямоугольника? Так как это NP задача нужно сокращать количество вариантов и не использовать заведомо ложные.
(могут быть еще и ограничения на структуры и здесь и поэтому количество поворотов ограничено но количество положений тля разных фигур различно)
А вот после получения некой картины на примитивах, можно уже крутить вертеть оригиналы.

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

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

E>>>Правда конкретно у портных вертеть фигуры НЕЛЬЗЯ.

S>> Почему, если не зависит от структуры Кожи или других материалов? Так скажем не портных а раскройщиков одежды.

E>Потому, что портные шьют из ткани, а её механические свойства анизотропны... (Свойства в направлении утка и основы сильно отличаются)...

А что с кожей http://lemarse.spb.ru/products/cut_leather/ которую я уже упоминал?
E>IMHO, это тут офтоп.
Да вся эта ветка оофтоп. Когда люди наследуют прямоугольник от квадрата и говорят, что это ООП
Но при этом когда очевидно что любая частная фигура это наследник более общего понятия Фигура, здесь начинается флейм, а зачем и для чего.
Доводы, того что для эффективной работы с фигурами тебе нужно знать особенности фигур просто отметаются. Ничего продуктивного в разговоре нет.
Единственный плюс, когда начинаешь спор рождаются новые мысли и идеи. Вот за это спасибо.

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

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

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

E>У термина "ООП" есть устоявшееся значение. Если хочешь, что бы тебя понимали, не стоит толковать его расширительно или нетрадиционно...

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

S>И наследование реализации — один из худших видов наследования.

Чем по-твоему наследование реализации отличается от композиции? если, конечно, отвлечься от слов и смотреть на суть.

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

S>>А вот резать мы их будем по единому алгоритму.
S>Резать вы будете не те фигуры, которые воображались в процессе размещения, а те реальные, которые заказаны. В алгоритме реза никакого полиморфизма нет: это, грубо говоря, язык HP-GL — набор команд по перемещению режущего инструмента.
А называй это как хочешь. ООП это не только полиморфизм, но и наследование реализации. Ты сын своего отца и матери. Полиморфизму (мутации) подверглись набор генов, но по сути ты являешься агрегатом части генов своих родителей и это реальное наследование. Как ты это будешь приспосабливать в программировании это твои проблемы. Но от этого понятие наследования не изменилось.

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

S> Ну если ты отбрасываешь наследование реализации, и наследуешь прямоугольник от квадрата, значит что то неправильно в этом термине.

Я вообще считаю, что в этой задачи предлагаемая тобой иерархия не нужна...

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

E>>>>Правда конкретно у портных вертеть фигуры НЕЛЬЗЯ.

E>>Потому, что портные шьют из ткани, а её механические свойства анизотропны... (Свойства в направлении утка и основы сильно отличаются)...

S>А что с кожей http://lemarse.spb.ru/products/cut_leather/ которую я уже упоминал?
Обычно с кожей работают таки скорняки, а не портные. И с кожеё тоже часто вертеть нельзя, кстати. Бывает кожа с заметным рисунком или мех...

S> Да вся эта ветка оофтоп. Когда люди наследуют прямоугольник от квадрата и говорят, что это ООП
Скорее всего можно придумать задачу, где это будет в тему, но мне ничего в голову не приходит.
В любом случае я разделяю мнение, что конкретно в геометрических задачах ООП для представления данных обычно не нужно, так же, как и в вычматах, например...

Просто специфика области. Всё удобно представлять векторами чего-то...

S>Но при этом когда очевидно что любая частная фигура это наследник более общего понятия Фигура, здесь начинается флейм, а зачем и для чего.
IMHO, очевидно, что это не так.
В целом, если "фигура вообще", это таки массив сегментов (дуг там, отрезков или ещё чего), то она самодостаточна и никакие наследники ей, так же как и друнгим массивам, не нужны.

Просто тот, треугольник, например, который ты тулишь этой фигуре в наследники, будет содержать на борту три доп. длины стороны, в целом избыточные, и ещё, может быть, угол поворота вокруг первой вершину, тоже избыточный. Это не наследник, а просто альтернативное представление

Ты же не считаешь, что комплексное число в нормальной форме является предком комплексного числа в экспонециальной?

S>Доводы, того что для эффективной работы с фигурами тебе нужно знать особенности фигур просто отметаются. Ничего продуктивного в разговоре нет.
Так у тебя просят примеры.
Ты привёл три примера.
1) Подсчёт периметра -- выигрыша от ООП нет вообще ниакого, только усложение.
2) Подсчёт площади -- от ООП проигрыш
3) Ограничение гипотез по размещению детали при раскрое -- ООП для задания списка дипазонов допустимых углов поворота нужно, то есть тоже усложнение без всякой пользы.

В целом это хорошо, но ещё лучше бы было привести примеры, которые демонстрируют твою правоту, а не правоту твоих оппонентов

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

S>>И наследование реализации — один из худших видов наследования.

DG>Чем по-твоему наследование реализации отличается от композиции? если, конечно, отвлечься от слов и смотреть на суть.
Тем, конечно, что композиция 1) не вводит отношения is-a, и 2) композиция работает на уровне объектов, а не классов. Побочным эффектом является возможность, в отличие от наследования, гибко выбирать тип компонуемого объекта.

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

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

S>> Ну если ты отбрасываешь наследование реализации, и наследуешь прямоугольник от квадрата, значит что то неправильно в этом термине.

E>Я вообще считаю, что в этой задачи предлагаемая тобой иерархия не нужна...

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

Здравствуйте, Serginio1, Вы писали:
S>А называй это как хочешь. ООП это не только полиморфизм, но и наследование реализации. Ты сын своего отца и матери. Полиморфизму (мутации) подверглись набор генов, но по сути ты являешься агрегатом части генов своих родителей и это реальное наследование. Как ты это будешь приспосабливать в программировании это твои проблемы. Но от этого понятие наследования не изменилось.
Чушь какая. Я вам рекомендую немедленно прекратить употреблять то, что вы употребляете, и начать после курса детоксикации читать какие-нибудь буквари. Потому что суть биологического наследования и суть наследования в ООП — принципиально разные.
То, что в них используются похожие слова, может ввести в заблуждение только ребёнка. Наследование — это всегда отношение is-a, проиллюстриованное принципом подстановки Лисков. Я не являюсь ни одним из своих родителей в этом смысле, поэтому утверждения типа "ты являешься агрегатом части генов своих родителей" с точки зрения программирования — бред. Кстати, с точки зрения биологии это тоже бред (потому, что живые организмы не состоят из генов).

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

S> Да ради Стандартной Модели. От этого прямоугольник не перестал быть фигурой. До ООП, народ прекрасно обходился без классов.
Угу. И вот эта программа в стиле "без классов" будет лушче того ООП-шного варианта, который ты предлагаешь...

IMHO, у тебя вообще какая-то проблема с теМ, что перепутаны статика и динамика. ООП оно обычно на уровне типов, а не на уровне объектов работает жеж...

S>То, что в них используются похожие слова, может ввести в заблуждение только ребёнка. Наследование — это всегда отношение is-a, проиллюстриованное принципом подстановки Лисков.

При строгом использовании терминов наследование вообще никакого отношения к is-a не имеет. Отношение is-a появляется при Subtyping (http://en.wikipedia.org/wiki/Subtype_polymorphism).

И это лишь исторически сложилось, что при нестрогом разговоре (даже в тексте википедии) явление subtyping подменяется явлением наследования.

Proof из той же вики:

In programming languages that do not support inheritance as a subtyping mechanism, the relationship between a base class and a derived class is only a relationship between implementations (a mechanism for code reuse), as compared to a relationship between types.

http://en.wikipedia.org/wiki/Inheritance_(object-oriented_programming)

E> ООП оно обычно на уровне типов, а не на уровне объектов работает жеж...

ООП бывает разное

Прототипное программирование — стиль объектно-ориентированного программированиях, при котором отсутствует понятие класса, а повторное использование (наследование) производится путём клонирования существующего экземпляра объекта — прототипа.

http://ru.wikipedia.org/wiki/%D0%9F%D1%80%D0%BE%D1%82%D0%BE%D1%82%D0%B8%D0%BF%D0%BD%D0%BE%D0%B5_%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5

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

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

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

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

S>Ну и так, для справки: математики, услышав словосочетание "площадь окружности", громко смеются. Так что если не желаете вызвать непреднамеренное веселье, постарайтесь применять термины по назначению.
Ну наверное это проще выговорить чем площадь материала очерченная окружностью.

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

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

S>>фигура

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

S>Shape Intersect(OtherShape)
S>

S>Если мы оставим "прямоугольность" там, где она должна быть, т.е. в виде extension метода bool IsRect(this Shape), то любая программа корректно опознает прямоугольник в результате вызова метода Intersect на вот такой паре фигур:
S>

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

)
S>>А эта сторона будет всего одна. Для других фигур для этого может потребоваться больше усилий.
S>Зачем вы всё делаете наоборот? Если стоит задача опускать в почтовый ящик конверты произвольной формы, то вам придётся один раз сесть и написать алгоритм нахождения наименьшего диаметра.
S>Но как только вы его напишете, вам будет не нужен алгоритм поиска наименьшего диаметра для прямоугольника. Так что "больше усилий" потребуется как раз для "использования данных прямоугольника в своих алгоритмах". Вам же Егор уже дважды подробно написал ровно эту мысль. Объясните, что именно мешает вам эту мысль понять?
Ну да вот зачем народ формулы площади круга, прямоугольников то придумывал. Конечно век компьютеризации, но вот беда то есть куча NP полных задач где нужно оптимизировать задачи.
Зачем ООП если можно в процедурном типе программировать. Да я могу использовать общий алгоритм, но в большинстве случаев он не оптимален по количеству затрачиваемого времени. Для каждой частной формы можно использовать свой алгоритм. Программирование это часть эволюции, а эволюция человечество это увеличение специализации и роста производительности труда.
Я даже отдельно для каждой частной фигуры напишу свой алгоритм прохождения, поворота для считывания индекса итд. А вот для не частных фигур я буду работать с базовым классом.

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

Кстати хотел задать вопрос по блокировкам. Не совсем понял
у тебя

Такая блокировка совместима с коллективной, что позволит читающим транзакциям обращаться к этим данным беспрепятственно. А когда понадобится их обновить, то проблем быть не должно, так как блокировки обновления между собой несовместимы, и значит, другие транзакции, читающие эти данные для последующего изменения (и естественно тоже запросившие их с блокировкой обновления), будут ждать, пока эти данные поменяются, никому не мешая. Для этого необходимо изменить первый оператор транзакции примерно таким образом:

SELECT @Var = Y FROM Tbl WITH (UPDLOCK) WHERE X = 2

На SQL http://www.sql.ru/forum/actualthread.aspx?tid=83697&pg=3&mid=668013#668013

1. Блокировки типа Update нужны для обозначения такого факта: те, кто уже имеет Shared locks на этот же ресурс могут продолжать ими пользоваться, но любые новые блокировки запрещены. Как только shared locks уходят с ресурса блокировка типа U конвертируется в eXclusive, чтобы обозначить соответственно названию, что никакими другими сессиями этот ресурс не заблокирован вообще. Держать блокировку до конца транзакции или нет — это совсем другой вопрос, решаемый REPEATABLE READ или HOLDLOCK.
Короче, смысл блокировок U — не блокировать данные _читаемые_ при выборке под UPDATE, а обозначать факт того, что мы намереваемся менять данные сразу после того как уйдут те, кто их сейчас читает.

То есть смысл второго, что UPDLOCK совместима с уже читающими и перед записью ждет окончания всех транзакций на чтение. Блокировки на чтение после начала Update, курят в сторонке.
Что с моей точки зрения логичней, т.к. можно обеспечить Repeatable read и при этом повысить параллельность. Хотя может у тебя это же и подразумевается а я не умею читать

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

S> Почему, разве я не могу заложить алгоритм в фигуру для оптимального её расположения относительно рядом лежащих фигур?

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

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

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

DG>Смешиваешь наследование интерфейса с наследованием реализации (может, конечно, это связано с тем, что в мейнстриме первое неотделимо от второго). Первое вводит отношение is-a, а наследование реализации никоим образом не вводит отношение is-a.
Курить LSP до просветления.

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

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

S>Ну наверное это проще выговорить чем площадь материала очерченная окружностью.
Проще вообще не говорить. А правильнее говорить "площадь круга".

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

S>Можно крутить вертеть, а можно зная характер характер текущей фигуры и рядом лежащих выбрать предпочтительное расположения, учитывая что у на NP полная задача.
Я вам больше отвечать, пожалуй, не буду. Мои аргументы вы не читаете, на вопросы не отвечаете, думать не хотите.

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

S>Конечно век компьютеризации, но вот беда то есть куча NP полных задач где нужно оптимизировать задачи.
Я вас разочарую: оптимизация NP-complete задач при помощи уменьшения множителя при O — это как чайной ложкой океан вычерпывать. И об этом вам тоже уже сказали минимум дважды. Это при том предположении, что ваша идея оптимизации через полиморфизм вообще имеет смысл: без профайлера заранее сказать, как повлияет вычисление площади на время работы программы, я лично бы не взялся.
А вы уже готовы педалить код — то есть растратить деньги инвестора на код, который себя скорее всего не оправдает.

S>Зачем ООП если можно в процедурном типе программировать.
Хороший вопрос. ООП — затем, чтобы уменьшить coupling и увеличить cohesion. Чтобы написать меньший объём кода, и чтобы внесение изменений обходилось дёшево. А по-вашему, зачем? Чтобы "моделировать реальный мир" что ли?

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

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

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

S>

S>1. Блокировки типа Update нужны для обозначения такого факта: те, кто уже имеет Shared locks на этот же ресурс могут продолжать ими пользоваться, но любые новые блокировки запрещены. Как только shared locks уходят с ресурса блокировка типа U конвертируется в eXclusive, чтобы обозначить соответственно названию, что никакими другими сессиями этот ресурс не заблокирован вообще. Держать блокировку до конца транзакции или нет — это совсем другой вопрос, решаемый REPEATABLE READ или HOLDLOCK.
S>Короче, смысл блокировок U — не блокировать данные _читаемые_ при выборке под UPDATE, а обозначать факт того, что мы намереваемся менять данные сразу после того как уйдут те, кто их сейчас читает.

S> То есть смысл второго, что UPDLOCK совместима с уже читающими и перед записью ждет окончания всех транзакций на чтение. Блокировки на чтение после начала Update, курят в сторонке.
S>Что с моей точки зрения логичней, т.к. можно обеспечить Repeatable read и при этом повысить параллельность. Хотя может у тебя это же и подразумевается а я не умею читать

В таких случаях надо обращаться к первоисточникам. Например, http://msdn.microsoft.com/en-us/library/ms186396(v=sql.105).aspx
Existing Granted Mode: U, Requested Mode: S: Yes.
То есть на этот раз угадал я, а не sql.ru.

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

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

S>> Почему, разве я не могу заложить алгоритм в фигуру для оптимального её расположения относительно рядом лежащих фигур?

E>Тогда надо уже мультиметоды мутить, так как алгоритм размещения одной фигуры у другой зависит от типа обеих...

E>Может таки лучше иметь массив сторон описанной фигуры и перебирать способы поставить сторону одного описывающего на сторону другого описывающего?..

Здесь как раз может иметь место 2 алгоритма один заложенный в фигуру, другой общий. При этом общий может быть и у любой произвольной фигуры. Это как аналог построения ДКА.
В одном случае можно сделать ветвление в другом создать семейство классов отвечающие за свое состояние и передачу выполнения следующему экземпляру класса отвечающее за свое состояние.
Конечно можно обойтись и интерфейсами но это будет семейство классов поддерживающий интерфейс.

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

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

S>>

S>>1. Блокировки типа Update нужны для обозначения такого факта: те, кто уже имеет Shared locks на этот же ресурс могут продолжать ими пользоваться, но любые новые блокировки запрещены. Как только shared locks уходят с ресурса блокировка типа U конвертируется в eXclusive, чтобы обозначить соответственно названию, что никакими другими сессиями этот ресурс не заблокирован вообще. Держать блокировку до конца транзакции или нет — это совсем другой вопрос, решаемый REPEATABLE READ или HOLDLOCK.
S>>Короче, смысл блокировок U — не блокировать данные _читаемые_ при выборке под UPDATE, а обозначать факт того, что мы намереваемся менять данные сразу после того как уйдут те, кто их сейчас читает.

S>> То есть смысл второго, что UPDLOCK совместима с уже читающими и перед записью ждет окончания всех транзакций на чтение. Блокировки на чтение после начала Update, курят в сторонке.
S>>Что с моей точки зрения логичней, т.к. можно обеспечить Repeatable read и при этом повысить параллельность. Хотя может у тебя это же и подразумевается а я не умею читать

S>В таких случаях надо обращаться к первоисточникам. Например, http://msdn.microsoft.com/en-us/library/ms186396(v=sql.105).aspx
S>Existing Granted Mode: U, Requested Mode: S: Yes.
S>То есть на этот раз угадал я, а не sql.ru.

Плохо у меня с английским. Просто для меня UPDLOCK вызывает противоречивые чувства. Если бы я делал блокировку то сделал бы по второму способу. Объясню почему
Например у меня есть намерение блокировать на запись и чтение на одинаковых строках но в разном направлении, что неминуемо приведет к дид луку. Но если я применю 2 вариант,
то новые транзакции будут заблокированы старые прочитают беспрепятственно уже заблокировнные записи и перед записью останется только подождать окончание читающих транзакций.

Метод когда UPDLOCK не приводит к блокировке новых транзакций не решает проблемы с одновременной экслюзивной и читающей блокировк строк в обратном порядке.

S> Плохо у меня с английским.
Омг. http://msdn.microsoft.com/ru-ru/library/ms186396(v=sql.105).aspx
Имхо, у вас не с английским плохо, а с чем-то более другим.

S>Просто для меня UPDLOCK вызывает противоречивые чувства. Если бы я делал блокировку то сделал бы по второму способу. Объясню почему
S>Например у меня есть намерение блокировать на запись и чтение на одинаковых строках но в разном направлении, что неминуемо приведет к дид луку. Но если я применю 2 вариант,
S>то новые транзакции будут заблокированы старые прочитают беспрепятственно уже заблокировнные записи и перед записью останется только подождать окончание читающих транзакций.

S>Метод когда UPDLOCK не приводит к блокировке новых транзакций не решает проблемы с одновременной экслюзивной и читающей блокировк строк в обратном порядке.
Решает. Параллельное программирование — сложная материя. Не торопитесь, распишите по шагам, кто что захватывает, сверяясь с таблицей блокировок. Судя по всему, вы вообще не понимаете сценарий применения U-блокировок.

Дизайн, выбранный в MS SQL, может встрять только в одном случае — когда идет интенсивный перезахват S-блокировок на ресурс, которго ждёт транзакция с конверсией U->X. В жизни это бывает относительно редко; как правило, рано или поздно читатели всё же уходят.

S>Курить LSP до просветления.

ты не стрелки переводи, а давай пруф, что LSP имеет хоть какое-то отношение к наследованию реализаций.

В определении LSP явно сказано, что LSP про subtyping, а не про наследование.

Substitutability is a principle in object-oriented programming. It states that, in a computer program, if S is a subtype of T, then objects of type T may be replaced with objects of type S (i.e., objects of type S may be substituted for objects of type T) without altering any of the desirable properties of that program (correctness, task performed, etc.). More formally, the Liskov substitution principle (LSP) is a particular definition of a subtyping relation, called (strong) behavioral subtyping, that was initially introduced by Barbara Liskov in a 1987 conference keynote address entitled Data abstraction and hierarchy

http://en.wikipedia.org/wiki/Liskov_substitution_principle

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

S>> Плохо у меня с английским.
S>Омг. http://msdn.microsoft.com/ru-ru/library/ms186396(v=sql.105).aspx
S>Имхо, у вас не с английским плохо, а с чем-то более другим.

S>>Просто для меня UPDLOCK вызывает противоречивые чувства. Если бы я делал блокировку то сделал бы по второму способу. Объясню почему
S>>Например у меня есть намерение блокировать на запись и чтение на одинаковых строках но в разном направлении, что неминуемо приведет к дид луку. Но если я применю 2 вариант,
S>>то новые транзакции будут заблокированы старые прочитают беспрепятственно уже заблокировнные записи и перед записью останется только подождать окончание читающих транзакций.

S>>Метод когда UPDLOCK не приводит к блокировке новых транзакций не решает проблемы с одновременной экслюзивной и читающей блокировк строк в обратном порядке.

Добавлю, что можно наложить ограничение на чтение U блокировок, только тем транзакциям у которых уже есть совместные блокировки. А это может быть когда читающая транзакция была начата раньше окончания U блокировки.
То есть всем транзакциям начавшимся позже окончания U блокировки отказывать в доступе.

S>Решает. Параллельное программирование — сложная материя. Не торопитесь, распишите по шагам, кто что захватывает, сверяясь с таблицей блокировок. Судя по всему, вы вообще не понимаете сценарий применения U-блокировок.

S>Дизайн, выбранный в MS SQL, может встрять только в одном случае — когда идет интенсивный перезахват S-блокировок на ресурс, которго ждёт транзакция с конверсией U->X. В жизни это бывает относительно редко; как правило, рано или поздно читатели всё же уходят.

Часто бывает интенсивное чтение например остатков и запись. Например Х блокировка блокирует записи 1,2,3,4 а S блокирует 4,3,2,1. Например S прочитала 4,3 а Х 1,2 что будет дальше?

S>Добавлю, что можно наложить ограничение на чтение U блокировок, только тем транзакциям у которых уже есть совместные блокировки. А это может быть когда читающая транзакция была начата раньше окончания U блокировки.
S>То есть всем транзакциям начавшимся позже окончания U блокировки отказывать в доступе.
Вы опять ставите телегу впереди лошади. Надо делать не то, что "можно", а то, что необходимо.

S>Часто бывает интенсивное чтение например остатков и запись. Например Х блокировка блокирует записи 1,2,3,4 а S блокирует 4,3,2,1. Например S прочитала 4,3 а Х 1,2 что будет дальше?
Дальше я вас отправлю читать какой-нибудь учебник, например того же Бернстайна. И попрошу постараться воздержаться от написания бреда. Блокировка ничего не читает и не пишет. Читает и пишет процесс в рамках некой транзакции.
А блокировки выдаются и снимаются, они связывают процесс с ресурсом.
Вот в вашем сумбурном примере сколько участвует процессов? Как устроен код этих процессов? Почему вы задаёте вопрос про U-блокировки, но в примере нет ни одной U-блокировки?

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

S>>Добавлю, что можно наложить ограничение на чтение U блокировок, только тем транзакциям у которых уже есть совместные блокировки. А это может быть когда читающая транзакция была начата раньше окончания U блокировки.
S>>То есть всем транзакциям начавшимся позже окончания U блокировки отказывать в доступе.
S>Вы опять ставите телегу впереди лошади. Надо делать не то, что "можно", а то, что необходимо.

S>>Часто бывает интенсивное чтение например остатков и запись. Например Х блокировка блокирует записи 1,2,3,4 а S блокирует 4,3,2,1. Например S прочитала 4,3 а Х 1,2 что будет дальше?
S>Дальше я вас отправлю читать какой-нибудь учебник, например того же Бернстайна. И попрошу постараться воздержаться от написания бреда. Блокировка ничего не читает и не пишет. Читает и пишет процесс в рамках некой транзакции.
S>А блокировки выдаются и снимаются, они связывают процесс с ресурсом.
S>Вот в вашем сумбурном примере сколько участвует процессов? Как устроен код этих процессов? Почему вы задаёте вопрос про U-блокировки, но в примере нет ни одной U-блокировки?

Процесс или поток? U блокировка это блокировка намерений. Так в примере с X блокировкой И U и S прекрасно пройдут без проблем и когда будет переход U->X нужно будет только подождать окончания S блокировок совместимые с U блокировками, т.к. транзакции начатые после окончания U блокировки будут блокированы. Хотя и здесь может ждать подводный камень, когда в момент U->X какая ни будь читающая транзакция не начнет
читать блокируемые записи.
Опять же давай абстрагируемся от БД и перейти на программирование для синхронизации одновременно выполняющихся потоков. Пусть U блокировка это расширенный ReaderWriterLock который кроме
AcquireReaderLock, AcquireWriterLock имеет метод AcquireUpdaterLock которые можно применять к любому объекту и соответственно. И предположим ситуацию когда на записи 1,2,3,4 будут применяться блокировки но в разных последовательностях.

Ого кстати а там есть UpgradeToWriterLock

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

S>Процесс или поток?
В СУБД используется термин "процесс".

S>U блокировка это блокировка намерений. Так в примере с X блокировкой И U и S прекрасно пройдут без проблем и когда будет переход U->X нужно будет только подождать окончания S блокировок совместимые с U блокировками, т.к. транзакции начатые после окончания U блокировки будут блокированы. Хотя и здесь может ждать подводный камень, когда в момент U->X какая ни будь читающая транзакция не начнет
S> читать блокируемые записи.
Не надо мне рассказывать, что такое блокировки. Поверьте мне, ничего нового вы не расскажете.
Вопрос в чём?

S>Опять же давай абстрагируемся от БД и перейти на программирование для синхронизации одновременно выполняющихся потоков. Пусть U блокировка это расширенный ReaderWriterLock который кроме
S>AcquireReaderLock, AcquireWriterLock имеет метод AcquireUpdaterLock которые можно применять к любому объекту и соответственно. И предположим ситуацию когда на записи 1,2,3,4 будут применяться блокировки но в разных последовательностях.
Ну, и в чём вопрос?

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

S> Здесь как раз может иметь место 2 алгоритма один заложенный в фигуру, другой общий. При этом общий может быть и у любой произвольной фигуры. Это как аналог построения ДКА.

Если общий работает плохо, то на кой он нужен вообще? Лучше уж тогда всё прямоугольниками, например, апроксимировать и не жужжать.
А если хорошо, то на кой нужен второй алгоритм?

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

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

S>>Процесс или поток?
S>В СУБД используется термин "процесс".

S>>U блокировка это блокировка намерений. Так в примере с X блокировкой И U и S прекрасно пройдут без проблем и когда будет переход U->X нужно будет только подождать окончания S блокировок совместимые с U блокировками, т.к. транзакции начатые после окончания U блокировки будут блокированы. Хотя и здесь может ждать подводный камень, когда в момент U->X какая ни будь читающая транзакция не начнет
S>> читать блокируемые записи.
S>Не надо мне рассказывать, что такое блокировки. Поверьте мне, ничего нового вы не расскажете.
S>Вопрос в чём?

S>>Опять же давай абстрагируемся от БД и перейти на программирование для синхронизации одновременно выполняющихся потоков. Пусть U блокировка это расширенный ReaderWriterLock который кроме
S>>AcquireReaderLock, AcquireWriterLock имеет метод AcquireUpdaterLock которые можно применять к любому объекту и соответственно. И предположим ситуацию когда на записи 1,2,3,4 будут применяться блокировки но в разных последовательностях.
S>Ну, и в чём вопрос?

Предположим, что AcquireUpdaterLock блокирует AcquireWriterLock,AcquireUpdaterLock, а AcquireReaderLock может блокироваться позже некоторого времени.
Предположим, что сначала мы применять записи к записям 1,2,3,4 и применить к ним AcquireWriterLock, одновременно к эти записям но в последовательности 4,3,2,1 идет другой поток и блокирует AcquireReaderLock
Первый например успел заблокировать 4,3 а второй 1,2 и соотвественно первый не может получить записи 3, а второй к 1. Дид лук.

Теперь вместо AcquireWriterLock применяем AcquireUpdaterLock но без блокировки AcquireReaderLock позже установки всех блокировок, при этом вариант при переходе из U в X не гарантирует, что что записи будут блокированы новой читающей транзакцией.
Если же мы применим блокировки и AcquireReaderLock когда дата начала транзакции меньше даты окончания U Блокировки, мы гарантируем что новые S блокировки не будут конфликтовать, а старые придется подождать.
С учетом, того если конечно старые S блокировки, ранее не учавствовавшие в блокировке записей U транзакции примутся за чтение любых записей когда уже начался переход U -> X.

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

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

S> Предположим, что AcquireUpdaterLock блокирует AcquireWriterLock,AcquireUpdaterLock, а AcquireReaderLock может блокироваться позже некоторого времени.
S>Предположим, что сначала мы применять записи к записям 1,2,3,4 и применить к ним AcquireWriterLock, одновременно к эти записям но в последовательности 4,3,2,1 идет другой поток и блокирует AcquireReaderLock
S>Первый например успел заблокировать 4,3 а второй 1,2 и соотвественно первый не может получить записи 3, а второй к 1. Дид лук.
Правильно.

S>Теперь вместо AcquireWriterLock применяем AcquireUpdaterLock но без блокировки AcquireReaderLock позже установки всех блокировок, при этом вариант при переходе из U в X не гарантирует, что что записи будут блокированы новой читающей транзакцией.
Поток мыслей неясен. Совершенно непонятно, зачем вы заменяете X на U.
U призвана починить ровно одну ситуацию: когда есть некая частая процедура, которая сначала получает S блокировку на ресурс, а потом, чуть позже, получает X блокировку на тот же ресурс.
Запуск двух экземпляров такого процесса приводит к дедлоку с большой вероятностью: оба получат S, и оба встанут при конверсии в X.
Чинится это захватом U вместо S. Не X на U! Заменить X на U нельзя, так как защищаемая X операция — запись. Из-за совместимости U и S читатели будут рисковать прочитать незакоммиченное значение

S>Лучше всего откатывать все такие S транзакции, в том числе и из-за соображения что записи вернут заведомо устаревшие данные.
Лучше всего почитать учебники по СУБД, например Бернстайна.

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

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

S>> Предположим, что AcquireUpdaterLock блокирует AcquireWriterLock,AcquireUpdaterLock, а AcquireReaderLock может блокироваться позже некоторого времени.
S>>Предположим, что сначала мы применять записи к записям 1,2,3,4 и применить к ним AcquireWriterLock, одновременно к эти записям но в последовательности 4,3,2,1 идет другой поток и блокирует AcquireReaderLock
S>>Первый например успел заблокировать 4,3 а второй 1,2 и соотвественно первый не может получить записи 3, а второй к 1. Дид лук.
S>Правильно.

S>>Теперь вместо AcquireWriterLock применяем AcquireUpdaterLock но без блокировки AcquireReaderLock позже установки всех блокировок, при этом вариант при переходе из U в X не гарантирует, что что записи будут блокированы новой читающей транзакцией.
S>Поток мыслей неясен. Совершенно непонятно, зачем вы заменяете X на U.
S>U призвана починить ровно одну ситуацию: когда есть некая частая процедура, которая сначала получает S блокировку на ресурс, а потом, чуть позже, получает X блокировку на тот же ресурс.
S>Запуск двух экземпляров такого процесса приводит к дедлоку с большой вероятностью: оба получат S, и оба встанут при конверсии в X.
S>Чинится это захватом U вместо S. Не X на U! Заменить X на U нельзя, так как защищаемая X операция — запись. Из-за совместимости U и S читатели будут рисковать прочитать незакоммиченное значение
Я заменяю X на U для того, чтобы сначала читать, а затем уже записывать. Типичный случай работы например в 1С. U блокировкой я заблокирую другие U и X блокировки, а сам буду читать совместно с S блокировками.
Но из этого можно еще получить дивиденды если запретить чтение S блокировками с датой больше даты окончания U блокировки, что бы исключить ситуацию с лил локами, а так же выдавать более точные данные.

S>>Лучше всего откатывать все такие S транзакции, в том числе и из-за соображения что записи вернут заведомо устаревшие данные.
S>Лучше всего почитать учебники по СУБД, например Бернстайна.
За книгу спасибо. Обязательно почитаю.

Здравствуйте, Serginio1, Вы писали:
S> Я заменяю X на U для того, чтобы сначала читать, а затем уже записывать.
То есть у вас сначала была X на всё время транзакции, а вы заменяете её на U, а затем X?
Ну да, это само работает.

S>Но из этого можно еще получить дивиденды если запретить чтение S блокировками с датой больше даты окончания U блокировки, что бы исключить ситуацию с лил локами, а так же выдавать более точные данные.
Нет, этих дивидендов получить не удастся. Как только у вас есть захват во встречном порядке двух (или более) ресурсов, то никакими ухищрениями вы от дедлока не избавитесь.
U лечит только дедлоки на единичном ресурсе.
Того же эффекта можно добиться, вообще отказавшись от апгрейда локов — то есть вместо S(R1), .... X(R1)... сразу хватать X(R1).
И единственный недостаток такого артиллерийского приёма — это блокировка чисто-S транзакций в течение первой фазы процесса, т.е. снижение concurrency.
Вот с ним и борются U-блокировки.
А вы пытаетесь построить комбинацию из версионника и блокировочника. Именно версионники используют сравнение "дат транзакций" для разруливания конкурентного доступа.

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

S>Здравствуйте, Serginio1, Вы писали:
S>> Я заменяю X на U для того, чтобы сначала читать, а затем уже записывать.
S>То есть у вас сначала была X на всё время транзакции, а вы заменяете её на U, а затем X?
S>Ну да, это само работает.

S>>Но из этого можно еще получить дивиденды если запретить чтение S блокировками с датой больше даты окончания U блокировки, что бы исключить ситуацию с лил локами, а так же выдавать более точные данные.
S>Нет, этих дивидендов получить не удастся. Как только у вас есть захват во встречном порядке двух (или более) ресурсов, то никакими ухищрениями вы от дедлока не избавитесь.
S>U лечит только дедлоки на единичном ресурсе.
S>Того же эффекта можно добиться, вообще отказавшись от апгрейда локов — то есть вместо S(R1), .... X(R1)... сразу хватать X(R1).

S>И единственный недостаток такого артиллерийского приёма — это блокировка чисто-S транзакций в течение первой фазы процесса, т.е. снижение concurrency.
S>Вот с ним и борются U-блокировки.

S>А вы пытаетесь построить комбинацию из версионника и блокировочника. Именно версионники используют сравнение "дат транзакций" для разруливания конкурентного доступа.

Но при этом мы не избавимся от большей части дид локов когда S читает 123456, а U->X 654321
Ну в версионнике хранятся предыдущие версии и там вообще нет кучи конфликтов. Просто у такого подхода 2 премущества это уменьшение конфликта при U->X и второе это чтение S более актуальных данных.
Просто подход высказанный на SQL.RU мне понравился.

Заметьте не я это предложил

Хотя близкие идеи ворошились в моей голове.

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

S>Но при этом мы не избавимся от большей части дид локов когда S читает 123456, а U->X 654321
И в "вашем" подходе тоже не избавимся. К тому же помните, что удержание S-локов применяется на уровне изоляции RR, а в RC они отпускаются по мере продвижения чтения. Поэтому к моменту, когда "читатель" запросит S-лок на 4, залоченный в X, он уже отпустит S-лок на 1, 2 и 3. Поэтому "писатель" спокойно сконвертирует свой U-лок на 3 в X и поедет дальше, а читатель останется ждать окончания транзакции писателя.

SS>

Хотя близкие идеи ворошились в моей голове.
Вы просто не понимаете, зачем предлагается решение на SQL.RU.
Оно решает редкую проблему: когда у меня есть транзакция, висящая на апгрейде U->X, и при этом у меня так много читателей, что их времена удержания локов перекрываются. То есть читатель1 читает ресурс, потом ресурс читает читатель2, и только теперь читатель1 отпускает лок. Но к моменту, когда читатель2 отпустит свой лок, уже прибежал читатель3 и захватил свой S-лок.
Мне всех читателей перечислять, или и так понятна природа проблемы?

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

Дата: 05.04.13 12:38

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

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

S>>Но при этом мы не избавимся от большей части дид локов когда S читает 123456, а U->X 654321
S>И в "вашем" подходе тоже не избавимся. К тому же помните, что удержание S-локов применяется на уровне изоляции RR, а в RC они отпускаются по мере продвижения чтения. Поэтому к моменту, когда "читатель" запросит S-лок на 4, залоченный в X, он уже отпустит S-лок на 1, 2 и 3. Поэтому "писатель" спокойно сконвертирует свой U-лок на 3 в X и поедет дальше, а читатель останется ждать окончания транзакции писателя.
Ну в итоге то мы хотим наложить блокировку RR. В 1С есть такое понятие как управляемые блокировки и их типы РежимБлокировкиДанных.Разделяемый и РежимБлокировкиДанных.Исключительный
первый действует так как с хинтом repeatableRead второй эХклюзивная блокировка. Сама транзакция в изоляции RC. Этим постоянно пользуюсь когда сначала нужно прочитать данные в режиме RR, либо например когда использыется несколько регистров по одному измерению делается регистр сведений и по нему ставится блокировки. Это дает возможность сократить количество блокированных записей.
Но это так отступление.Просто есть куча регистров где используется постоянное чтение, которые изменяются с достаточно малой переодичностью. И вот U блокировки с возможностью X для S блокировок с датой начала более даты окончания U блокировки увеличила бы скорость проведения и уменьшила конфликты.
У меня сейчас нет 8 ки а то можно было бы посмотреть в профайлере что выдает
Блокировка = Новый БлокировкаДанных;
ЭлементБлокировки = Блокировка.Добавить("РегистрНакопления.ТоварыНаСкладах");
ЭлементБлокировки.Режим = РежимБлокировкиДанных.Разделяемый;
ЭлементБлокировки.УстановитьЗначение("Номенклатура",Товар);
ЭлементБлокировки.УстановитьЗначение("Склад",Склад);

SS>> Хотя близкие идеи ворошились в моей голове.
S>Вы просто не понимаете, зачем предлагается решение на SQL.RU.
S>Оно решает редкую проблему: когда у меня есть транзакция, висящая на апгрейде U->X, и при этом у меня так много читателей, что их времена удержания локов перекрываются. То есть читатель1 читает ресурс, потом ресурс читает читатель2, и только теперь читатель1 отпускает лок. Но к моменту, когда читатель2 отпустит свой лок, уже прибежал читатель3 и захватил свой S-лок.
S>Мне всех читателей перечислять, или и так понятна природа проблемы?
Это ничем не отличается от просто X. С точки зрения ReaderWriterLock.AcquireWriterLock просто ставит в очередь всех кто хочет иметь доступ к записи.
ReaderWriterLock.AcquireWriterLock аналог UpgradeUpdaterLockToWriterLock должен просто изменить U->X, но так как для новых записей на блокировку нет, а старые уже в большинстве случаев могут уйти мы реально увеличим скорость проведения учитывая время на чтение в этой транзакции.

Здравствуйте, Serginio1, Вы писали:
S>Ну в итоге то мы хотим наложить блокировку RR.
Нет такой блокировки.
S> В 1С есть такое понятие как управляемые блокировки и их типы РежимБлокировкиДанных.Разделяемый и РежимБлокировкиДанных.Исключительный
S> первый действует так как с хинтом repeatableRead второй эХклюзивная блокировка.
То есть это Shared + HoldLock?

S>Сама транзакция в изоляции RC. Этим постоянно пользуюсь когда сначала нужно прочитать данные в режиме RR, либо например когда использыется несколько регистров по одному измерению делается регистр сведений и по нему ставится блокировки. Это дает возможность сократить количество блокированных записей.
S>Но это так отступление.Просто есть куча регистров где используется постоянное чтение, которые изменяются с достаточно малой переодичностью. И вот U блокировки с возможностью X для S блокировок с датой начала более даты окончания U блокировки увеличила бы скорость проведения и уменьшила конфликты.
Простите, но после окончания U блокировки любые другие блокировки уже не будут её учитывать.
Вы что-то катастрофически путаете.

S>Это ничем не отличается от просто X. С точки зрения ReaderWriterLock.AcquireWriterLock просто ставит в очередь всех кто хочет иметь доступ к записи.
Это отличается тем, что а) я могу получить U и начать читать, не дожидаясь, пока все читатели уйдут и б) читатели могут продолжать получать S, пока я не сконвертился в X.

S>ReaderWriterLock.AcquireWriterLock аналог UpgradeUpdaterLockToWriterLock должен просто изменить U->X, но так как для новых записей на блокировку нет, а старые уже в большинстве случаев могут уйти мы реально увеличим скорость проведения учитывая время на чтение в этой транзакции.
Непонятно, что и за счёт чего вы увеличите. Кто-то из нас катастрофически не понимает возможные последовательности событий при выполнении транзакций. Смею полагать, что это не я.

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

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

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

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

Для прямоугольного треугольника это может быть только одна точка,

С какого перепугу только одна?

S>с ограинчением расположения треугольника в 4 положениях.

С какого перепугу ограничено только 4 положениями?

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

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

Ликбез: http://www.youtube.com/watch?v=U4Hv494HwrQ

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

S>Здравствуйте, Serginio1, Вы писали:
S>>Ну в итоге то мы хотим наложить блокировку RR.
S>Нет такой блокировки.
S>> В 1С есть такое понятие как управляемые блокировки и их типы РежимБлокировкиДанных.Разделяемый и РежимБлокировкиДанных.Исключительный
S>> первый действует так как с хинтом repeatableRead второй эХклюзивная блокировка.
S>То есть это Shared + HoldLock?
WITH(REPEATABLEREAD) например http://www.sql.ru/forum/actualthread.aspx?tid=1009095

S>>Сама транзакция в изоляции RC. Этим постоянно пользуюсь когда сначала нужно прочи
S>>ReaderWriterLock.AcquireWriterLock аналог UpgradeUpdaterLockToWriterLock должен просто изменить U->X, но так как для новых записей на блокировку нет, а старые уже в большинстве случаев могут уйти мы реально увеличим скорость проведения учитывая время на чтение в этой транзакции.
S>Непонятно, что и за счёт чего вы увеличите. Кто-то из нас катастрофически не понимает возможные последовательности событий при выполнении транзакций. Смею полагать, что это не я.
Давай посчитаем например время записывающей транзакции состоит из времени чтения Х и времени записи Y = Z.
Так с моей блокировкой время чтения может быть равно времени текущий читающих транзакция блокировавших записи при этом время транзакции останется Z.
При X и U по твоей методике будет Z+ время ожидания снятия S блокировок и может быть соизмеримо с временем чтения читающей транзакции то есть время будет ~ 2Х+Y

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

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

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

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

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

Для прямоугольного треугольника это может быть только одна точка,

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

A>С какого перепугу ограничено только 4 положениями?

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

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

A>Ликбез: http://www.youtube.com/watch?v=U4Hv494HwrQ

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

Для прямоугольного треугольника это может быть только одна точка,

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

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

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

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

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

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

Какая разница? Это останется задачей «повернуть многоугольник на N градусов вокруг точки Z».

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

Здравствуйте, 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 где можно отловить закономерности расположения фигур.

От:	Serginio1	https://habrahabr.ru/users/serginio1/topics/
Дата:	26.03.13 08:37
Оценка:

От:	Ikemefula	http://blogs.rsdn.org/ikemefula
Дата:	26.03.13 10:03
Оценка:	+1

От:	Sinclair	https://github.com/evilguest/
Дата:	27.03.13 06:52
Оценка:	+4

	От:	Erop
	Дата:	01.04.13 18:28
	Оценка:	+3

	От:	Erop
	Дата:	01.04.13 16:46
	Оценка:	81 (2)

От:	Философ	http://vk.com/id10256428
Дата:	01.04.13 20:24
Оценка:	+2

От:	DarkGray	http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата:	03.04.13 09:27
Оценка:	-1

От:	_Obelisk_	http://www.ibm.com
Дата:	07.04.13 06:55
Оценка:	+1

От:	Mamut	http://dmitriid.com
Дата:	02.04.13 15:26
Оценка: