Здравствуйте, Serginio1, Вы писали: S>В реальной жизни многие классы имеют множественное наследование, поэтому главное выбрать основного предка и правильно спроектировать иерархию.
В реальной жизни никаких классов нет.
Классы — это наш способ моделировать реальность. И это — далеко не единственный способ. Посмотрите на javascript — он прекрасно обходится без классов, и многие аспекты реальных объектов его подход моделирует гораздо лучше.
S>Кстати не понимаю почему в Net нет такого понятия как Implements, когда за реализацию интерфейса отвечает конкретное поле. А так приходится городить интерфейсные методы и свойства на этом поле.
Потому что не стали усложнять платформу встроенной поддержкой агрегации. Она не так проста, как кажется.
S>Или применять подход как запрос интерфейса у объекта. И вот он появился первый предок у которого есть понятие тип, вид, И метод или интерфейс с методом ДайкаМнеНужныйИнтерфейс()
Запрос интерфейса у объекта в дотнете вполне себе есть. То, как он сделан в COM, который вас вдохновляет, напрямую связано с поддержкой агрегации. А её, в свою очередь, сделали потому, что наследования реализации в COM сделать не получилось.
S> Затем появляются абстрактные справочник,Документ, регистры. Регистры сведений тоже имею иерархию периодические непериодические. S>А вот дальше сложнее. Нужно выделить частоиспользуемы, а значит и более затратные в алгоритмах. Например списание, перемещение, реализация имеют одинаковое свойство как списание с регистров товара.
S>С другой стороны Поступление оприходование и то же перемещение имеют свойство оприходования товара. Но при этом у них должны быть поля табличной части и документа одинаковыми для отражения их в регистрах учета. S>И вот здесь можно выделить базового родителя у которого есть такие поля а от него уже отнаследовать документы для поступления и списания. Гермофродита типа перемещение нужно отрабатывать через интерфейс который будут поддерживать и наследники от поступления.
Ключевое заблуждение выделено. Вся проблема — в том, что никакого наследования "на самом деле" нет. Никто не заводит новый тип документа в бухгалтерии как "давайте отнаследуемся от накладной на поступление и перекроем кое-какие виртуальные методы". Просто есть некий workflow, есть нужные для него реквизиты, и есть документ с этими реквизитами. Это вы приходите со своим замыленным ООП взглядом и говорите "о! давайте отнаследуем всё от документа ХХХ".
А всё почему? Из-за непонимания ООП. ООП — оно целиком про поведение. Структура — вторична. Это очень частая ошибка — строить иерархию наследования исходя из имеющихся атрибутов. Именно это заблуждение побуждает наследовать прямоугольник от квадрата.
Надо строить иерархию, исходя из поведения.
Как только это становится понятным, сразу всё облегчается. У документов поведения, связанного со складом, нету вовсе. "Куда ведёт эта дорога? — Сколько я себя помню, эта дорога лежала себе там же, где и лежит". Документ всего лишь отражает некоторые факты, это и есть его обязанность. А принимать решения о корректировке складских остатков должен кто-то другой — тот, кто знает, чем LIFO отличается от FIFO, и каким образом хранится информация о партиях на складе.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
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() у полигона будет что-то там такое умное считать, а вот у его наследника треугольника будет считать по простой формуле?..
Ты уверен, что это будет более выгодно, чем просто написать
Кроме того, я сильно подозреваю, что обычный алгоритм суммирования по трапециям
(x[i]-x[i+1])*(y[i]+y[i+1])/2
всё равно проще формулы для треугольика и в допю оптимизациях не нуждается...
Так примеры того, зачем треугольник выводить из многоугольника будут?..
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
E>Кроме того, я сильно подозреваю, что обычный алгоритм суммирования по трапециям
(x[i]-x[i+1])*(y[i]+y[i+1])/2
всё равно проще формулы для треугольика и в допю оптимизациях не нуждается...
E>Так примеры того, зачем треугольник выводить из многоугольника будут?..
Ну я уже упоминал тебе карты раскроя. Для каждого вида фигур можно сделать либо общий алгорить перебора с поворотами на определенные углы. Так если не брать структуру, то для прямоугольников углы будут строго ограничены и иметь 2 вида положения, для треугольников 4, для окружности 1.
При этом оперировать проще простыми фигурам к которым можно приводить по похожести, а вот раскрой делать по набору точек. И есть явное наследование от фигуры с массивом точек.
и солнце б утром не вставало, когда бы не было меня
S> Еще раз треугольник наследуется не от квадрата, а от абстрактной фигуры с массивом точек и абстрактными методами периметр и площадь.
А зачем периметр или площадь треугольника вычитать иным способом, чем периметр и площадь N-уголника?
Тебя же просят привести пример РЕАЛЬНОГО алгоритма, где это всё было бы востребовано?..
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Erop, Вы писали:
E>Здравствуйте, Serginio1, Вы писали:
S>> Еще раз треугольник наследуется не от квадрата, а от абстрактной фигуры с массивом точек и абстрактными методами периметр и площадь.
E>А зачем периметр или площадь треугольника вычитать иным способом, чем периметр и площадь N-уголника?
E>Тебя же просят привести пример РЕАЛЬНОГО алгоритма, где это всё было бы востребовано?..
А зачем тратить лишнее время. Сколько точек нужно для расчета периметра илм площади для окружности?
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
S> А вот для алгоритмов раскроя это очень важно. При этом оперировать проще простыми фигурам к которым можно приводить по похожести, а вот раскрой делать по набору точек. И есть явное наследование от фигуры с массивом точек.
Почему наследование? Ты типа делаешь, кроме типа "фигура" ещё и тип "фигура в коробочке простой формы". Зачем вторая должна быть наслдником, а не агрегатором первой?
Мало того, "коробочка простой формы" тоже скорее всего не нуждается в том, что бы быть полиморфной...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Erop, Вы писали:
E>Здравствуйте, Serginio1, Вы писали:
S>> Еще раз треугольник наследуется не от квадрата, а от абстрактной фигуры с массивом точек и абстрактными методами периметр и площадь.
E>А зачем периметр или площадь треугольника вычитать иным способом, чем периметр и площадь N-уголника?
E>Тебя же просят привести пример РЕАЛЬНОГО алгоритма, где это всё было бы востребовано?..
Я уже приводил пример с картами раскроя. Так прямоугольный крой стоит дешевле чем криволинейный. Кроме того есть кромкование которое зависит от периметра.
Оптимальность раскроя зависит от общей площади деталей к площади листа. Ну и алгоритмы раскроя достаточно жадные до ресурсов и относятся к классу NP-полная задача
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Erop, Вы писали:
E>Здравствуйте, Serginio1, Вы писали:
S>> А вот для алгоритмов раскроя это очень важно. При этом оперировать проще простыми фигурам к которым можно приводить по похожести, а вот раскрой делать по набору точек. И есть явное наследование от фигуры с массивом точек.
E>Почему наследование? Ты типа делаешь, кроме типа "фигура" ещё и тип "фигура в коробочке простой формы". Зачем вторая должна быть наслдником, а не агрегатором первой?
E>Мало того, "коробочка простой формы" тоже скорее всего не нуждается в том, что бы быть полиморфной...
А чем плохо наследование, если оно реально присутствует и отвечает за частные случаи. То есть Квадрат это фигура состоящая из 4 точек итд?
В одних случаях хорошо оперировать как квадрат в других случаях как фигура. Так человек это млекопитающего и его внутренние органы соответствуют свинье итд.
При этом свинья выступает во многих случаях как моделью для изучения влияния различных воздействий.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
S>При этом оперировать проще простыми фигурам к которым можно приводить по похожести, а вот раскрой делать по набору точек. И есть явное наследование от фигуры с массивом точек.
Я бы, вот, например, сделал бы сразу такое понятие, как "гипотеза размещения", которая содерала бы в себе поворот, сдвиг и упрощённый объемлющий полигон исходного полигона, при помощи которого можно быстро проверить что что полигоны не пересекаются, ну и сам исходный полигон или ссылку на него.
Потом по соображениям подобия там, или ещё каким-то эвристикам, строил бы по каждому полигону массив гипотез, а потом перебирал бы их как-то целенаправленно...
А как делаешь ты? Вот, например, у тебя в качестве упрощённых фигур есть круг, треугольник, прямоугольник, квадрат и элипс. Как ты, например, проверяешь, что нет пересечений?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Serginio1, Вы писали:
S> А зачем тратить лишнее время. Сколько точек нужно для расчета периметра илм площади для окружности?
Если ты хранишь окружность, как дугу кривой какого-то семейства, то три-четыре, в зависимости от того, какое семейство кривых...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Serginio1, Вы писали:
S> А зачем тратить лишнее время. Сколько точек нужно для расчета периметра илм площади для окружности?
А ты окружность наследуешь из полигона с каким числом вершин, кстати?..
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
E>Почему наследование? Ты типа делаешь, кроме типа "фигура" ещё и тип "фигура в коробочке простой формы". Зачем вторая должна быть наслдником, а не агрегатором первой?
То есть ты утверждаешь, что квадрат это не фигура, или излишне вводить новую сущность как прямоугольный треугольник, прямоугольник, квадрат итд и достаточно всего массива набора точек?
А может они введены для упрощения многих алгоритмов, в том числе и для базовых (тригонометрия например)
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Erop, Вы писали:
E>Здравствуйте, Serginio1, Вы писали:
S>>При этом оперировать проще простыми фигурам к которым можно приводить по похожести, а вот раскрой делать по набору точек. И есть явное наследование от фигуры с массивом точек.
E>Я бы, вот, например, сделал бы сразу такое понятие, как "гипотеза размещения", которая содерала бы в себе поворот, сдвиг и упрощённый объемлющий полигон исходного полигона, при помощи которого можно быстро проверить что что полигоны не пересекаются, ну и сам исходный полигон или ссылку на него. E>Потом по соображениям подобия там, или ещё каким-то эвристикам, строил бы по каждому полигону массив гипотез, а потом перебирал бы их как-то целенаправленно...
E>А как делаешь ты? Вот, например, у тебя в качестве упрощённых фигур есть круг, треугольник, прямоугольник, квадрат и элипс. Как ты, например, проверяешь, что нет пересечений?
Я возьму и приведу их всех к вписанному прямоугольнику. И там по упрощенному алгоритму проверю, на пересечение. Если нет пересечений прямоугольников значит и нет пересечений многополигомных фигур. Если же пересекаются, то перехожу к более сложным фигурам.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
S>Я уже приводил пример с картами раскроя. Так прямоугольный крой стоит дешевле чем криволинейный. Кроме того есть кромкование которое зависит от периметра.
Ничего не понимаю. Кривой у теюя там крой или прямой зависит от самих по себе фигур,а не от карты.
Общая длина реза зависит от того, как много границ удаётся совместить с граиницами слэба или границами деталей, но как раз тут и НЕЛЬЗЯ приближать фигуру упрощённой формой.
Общая длина кромкования вообще зависит только от самих деталей
S>Оптимальность раскроя зависит от общей площади деталей к площади листа.
Забыл ещё возможность переиспользования реза. То есть что бы один рез разделял соразу две детали.
S>Ну и алгоритмы раскроя достаточно жадные до ресурсов и относятся к классу NP-полная задача
Ну они же жадные в области перебора вариантов размещения деталей, а не в области обсчёта конкретного варианта. Конечно детали можно для кроя немного упростить. Ну там совсем кривые края спрямить с запасом, и пометить, что переиспользование этой границы не является выигрышем, убрать с деталей всякие пазы щели и дырки, и т. д. Но в целом вычислить размещение реального полигона или упрощённого -- это разница всего-то в разы. Не в разы разница -- это структура перебора вариантов. Её-то и надо оптимизировать, а не фигню.
ну и потом, выч. мощность очень дешёвая, на самом деле. А раскрой часто довольно дорог. Так что вообще не понятно, какой экономический смысл экономить на компике, что бы потом переплачивать за резку...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Erop, Вы писали:
E>Здравствуйте, Serginio1, Вы писали:
S>> А зачем тратить лишнее время. Сколько точек нужно для расчета периметра илм площади для окружности?
E>Если ты хранишь окружность, как дугу кривой какого-то семейства, то три-четыре, в зависимости от того, какое семейство кривых...
Во пошло. А Дуга это разве не фигура? Опять же при раскрое ты будешь оперировать шагом итд. Вот мы пришлу уже к иерархии называемой семейством.
Которая является фигурой и которую можно выразить через массив точек с определенным шагом.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Erop, Вы писали:
E>Здравствуйте, Serginio1, Вы писали:
S>> А зачем тратить лишнее время. Сколько точек нужно для расчета периметра илм площади для окружности?
E>А ты окружность наследуешь из полигона с каким числом вершин, кстати?..
А ничего смешного то здесь нет. В криврлинейке там можно задавать и полигон, и сплайны итд.
и солнце б утром не вставало, когда бы не было меня
