Представьте себе ситуацию — есть у меня абстрактный класс Geometry , под которым мы понимаем некоторый геметрический объект. От него наследуются классы Point, Line , ну и Polygon. В Geometry определён абстрактный виртуальный метод BOOL Geometry::IsOverlap (Geometry * AnotherGeometry), который просто показывает, есть ли у этих объектов общие точки. Есть своя реализация этого метода в каждом из потомков — то есть в классах Point, Line и Polygon. Но тут возникает следующая проблема. Класс Polygon, в принципе, должен знать только о себе, то есть он сможет определить, пересекается ли он с другим полигоном. А как же быть с остальными фигурами? Можно, конечно, в каждом классе выяснять, что за объект туда поступает и на основе этого вычислять, пересекается или нет. Но тогда получается, что если мы сделаем замену в классе полигона, то придётся переписывать все остальные классы. Каким образом надо действовать? Как реализовывать этот метод? Помогите советом! :???:

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

Каким образом надо действовать? Как реализовывать этот метод? Помогите советом!

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

int CombineRgn(
  HRGN hrgnDest,      // handle to destination region
  HRGN hrgnSrc1,      // handle to source region
  HRGN hrgnSrc2,      // handle to source region
  int fnCombineMode   // region combining mode
);

где fnCombibeMode = RGN_AND
В результате получится многоугольник пересечения.
Если функция вернёт NULLREGION, то пересечения нет.
Другое дело, если ты пишешь без использования API, тогда тебе придётся реализовать функции проверки самостоятельно

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

A>Представьте себе ситуацию — есть у меня абстрактный класс Geometry , под которым мы понимаем некоторый геметрический объект. От него наследуются классы Point, Line , ну и Polygon. В Geometry определён абстрактный виртуальный метод BOOL Geometry::IsOverlap (Geometry * AnotherGeometry), который просто показывает, есть ли у этих объектов общие точки. Есть своя реализация этого метода в каждом из потомков — то есть в классах Point, Line и Polygon. Но тут возникает следующая проблема. Класс Polygon, в принципе, должен знать только о себе, то есть он сможет определить, пересекается ли он с другим полигоном. А как же быть с остальными фигурами? Можно, конечно, в каждом классе выяснять, что за объект туда поступает и на основе этого вычислять, пересекается или нет. Но тогда получается, что если мы сделаем замену в классе полигона, то придётся переписывать все остальные классы. Каким образом надо действовать? Как реализовывать этот метод? Помогите советом!

Ну не знаю что тебе посоветовать, но:
проблема по-моему не в реализации классов, а в подходе к пересечению. Как ты сможешь пересечь 2 фигуры если тебе обе (или одна из них) не известны? Посморти в WinAPI, там есть один общий, так сказать, "класс" под названием region, который получается пересечением примитивов. Так вот любой алгоритм пересечения будет исходить из структуры твоего объекта Geometry, которая должна быть известна и достаточно абстрактна (и однообразна для всех подклассов). Подходы могут быть: набор примитивов (например триангуляция) или по границам и др. Примерно вот такая мысль.
ЗЫ. IsOverlap — это не есть осмысленное выражение, пологичнее было бы overlaps или intersects

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

A>Каким образом надо действовать? Как реализовывать этот метод? Помогите советом!

Безупречного решения этой проблемы вроде нет.
Твой вопрос очень подробно обсуждался Скоттом Мейерсом в Наиболее эффективном использовании C++

Автор(ы): Скотт Мейерс
В новой книге Скотта Мейерса, которая является
продолжением популярного издания
"Эффективное использование C++",
приводятся рекомендации по
наиболее эффективному использованию конструкций языка C++. Рассматриваются
правила перегрузки операторов, способы приведения типов, реализация механизма
RTTI и многое другое. Даны практические советы по применению буферизованного
оператора new, виртуальных конструкторов, интеллектуальных указателей,
proxy-классов и двойной диспетчеризации. Особое внимание уделяется работе с
исключениями и возможностям использования кода С в программах, написанных на
C++. Подробно описаны новейшие средства языка и показано, как с их помощью
повысить производительность программ. Приложения содержат код шаблона auto_ptr и
аннотированный список литературы и Internet-ресурсов, посвященных C++.

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

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

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

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

D>Здравствуйте Рома, Вы писали:

D>Ребята, а чего вы пытаетесь засунуть этот вопрос в алгоритмы.
D>По моему с чисткой рядов не надо перебарщивать, ведь вопрос касается объектной модели системы классов, чего вы его сунете в алгоритмы

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

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

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

D>>Здравствуйте Рома, Вы писали:

D>>Ребята, а чего вы пытаетесь засунуть этот вопрос в алгоритмы.
D>>По моему с чисткой рядов не надо перебарщивать, ведь вопрос касается объектной модели системы классов, чего вы его сунете в алгоритмы :no:

К>вообще-то я не знал куда его пихать, как бы к c++ он прямого-то отношения не имеет, скорее его бы в проектирование, но там какие-то не совсем те темы, т.е. даже скорее в прочее, хотя ИМХО проблема в данном случае отчасти лежит в алгоритме как раз.


Меня интересует имеено ОБЪЕКТНАЯ МОДЕЛЬ....
то есть как надо делать — какие классы и всё такое..
дело даже не в алгоритме пересечения

Здравствуйте Аноним, Вы писали:

А>Меня интересует имеено ОБЪЕКТНАЯ МОДЕЛЬ....
А>то есть как надо делать — какие классы и всё такое..
А>дело даже не в алгоритме пересечения

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

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

К>хотя ИМХО проблема в данном случае отчасти лежит в алгоритме как раз.

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

Здравствуйте Аноним, Вы писали:

А>Здравствуйте Курилка, Вы писали:

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

D>>>Здравствуйте Рома, Вы писали:

D>>>Ребята, а чего вы пытаетесь засунуть этот вопрос в алгоритмы.
D>>>По моему с чисткой рядов не надо перебарщивать, ведь вопрос касается объектной модели системы классов, чего вы его сунете в алгоритмы

К>>вообще-то я не знал куда его пихать, как бы к c++ он прямого-то отношения не имеет, скорее его бы в проектирование, но там какие-то не совсем те темы, т.е. даже скорее в прочее, хотя ИМХО проблема в данном случае отчасти лежит в алгоритме как раз.


А>Меня интересует имеено ОБЪЕКТНАЯ МОДЕЛЬ....
А>то есть как надо делать — какие классы и всё такое..
А>дело даже не в алгоритме пересечения

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

Что-то на ночь глядя в теорию потянуло...

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

К>Здравствуйте Аноним, Вы писали:

А>>Здравствуйте Курилка, Вы писали:

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

D>>>>Здравствуйте Рома, Вы писали:

D>>>>Ребята, а чего вы пытаетесь засунуть этот вопрос в алгоритмы.
D>>>>По моему с чисткой рядов не надо перебарщивать, ведь вопрос касается объектной модели системы классов, чего вы его сунете в алгоритмы :no:

К>>>вообще-то я не знал куда его пихать, как бы к c++ он прямого-то отношения не имеет, скорее его бы в проектирование, но там какие-то не совсем те темы, т.е. даже скорее в прочее, хотя ИМХО проблема в данном случае отчасти лежит в алгоритме как раз.


А>>Меня интересует имеено ОБЪЕКТНАЯ МОДЕЛЬ....
А>>то есть как надо делать — какие классы и всё такое..
А>>дело даже не в алгоритме пересечения

К>Ну если так подходить, то с объектной моделью у тебя всё в порядке...
К>Другое дело, что такая абстрактная модель очень плохо работает, когда ты пытаешься реализовать
К>алгоритм, необходимый в ней.
К>Т.е. нельзя строить иерархию классов и интерфейсов не беря в рассчёт механизмы их взаимодействия (т.е. алгоритмы).

К>Что-то на ночь глядя в теорию потянуло...




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

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

D>Здравствуйте Аноним, Вы писали:

D>Не переживай совместными усилиями мы тебя отстояли
D>А вообще-то надо давно расписать тематику форумов (Денис где ты), чтобы не было таких споров.

Да ладно, я сам не очень был уверен, что делать с этим топиком, если честно.
Извиняюсь за оффтопик, но на твой взгляд где сейчас место вопросам про "ОБЪЕКТНЫЕ МОДЕЛИ"?
По-моему определённого места на форуме сейчас нет (лучше всего "проектирование", но та тема забита топиками скорее о разработке, чем о "software design").

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


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

Ага. Только выяснять тип обьекта нельзя. Лучше использовать virtual функции.

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

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

Умная идея, позволяет абстрагироваться от алгоритма пересечения...
Однако это переносит проблему распознания объектов в этот алгоритм, а в принципе разные алгоритмы используют разные данные. Т.е. проблемы ещё те, ну да ладно — пойду я домой, буду рад завтра с утра почитать новые умные мысли по этому поводу.

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

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


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

Р>Ага. Только выяснять тип обьекта нельзя. Лучше использовать virtual функции.


Хе! в том-то и дело! какую виртуальную функцию ты здесь предложишь? Можно, конечно, пофантазировать — типа она будет возвращать все точки этого объекта. Но тогда просто и без интерфейсного класса обойтись! ТИпа блин просто прописать это в каждом — вызов Geometry::GEtPOints — и просто смотреть, есть ли совпадающие с GEtPOints у тебя..
Но это же лажа — все точки возвращать!

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

A>Здравствуйте Рома, Вы писали:

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


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

Р>>Ага. Только выяснять тип обьекта нельзя. Лучше использовать virtual функции.


A>Хе! в том-то и дело! какую виртуальную функцию ты здесь предложишь? Можно, конечно, пофантазировать — типа она будет возвращать все точки этого объекта. Но тогда просто и без интерфейсного класса обойтись! ТИпа блин просто прописать это в каждом — вызов Geometry::GEtPOints — и просто смотреть, есть ли совпадающие с GEtPOints у тебя..
A>Но это же лажа — все точки возвращать!
Неа и линию и круг можно описать как регион

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

Р>Неа и линию и круг можно описать как регион

HRGN CreateEllipticRgn(
  int nLeftRect,   // x-coord of the upper-left corner of the bounding rectangle
  int nTopRect,    // y-coord of the upper-left corner of the bounding rectangle
  int nRightRect,  // x-coord of the lower-right corner of the bounding rectangle
  int nBottomRect  // y-coord of the lower-right corner of the bounding rectangle
);

Вот эллипс, к примеру. Линия описывается тривиально.

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

A>Представьте себе ситуацию...

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

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

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

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

A>>Представьте себе ситуацию...

IT>Если тебя интересует в первую очередь объектная модель, а не эффективность, то можно ввести объект описывающие фигуру не в её родных примитивах (окружностях, длинах, углах), а неких универсальных (возможно даже для частного случая) примитивах (например, точках и/или векторах). Все твои объекты должны уметь создавать/заполнять такие объекты (назовём их регионы), ну а алгоритмы пересечения нужно делать уже для регионов.

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


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

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

IT>>Если тебя интересует в первую очередь объектная модель, а не эффективность, то можно ввести объект описывающие фигуру не в её родных примитивах (окружностях, длинах, углах), а неких универсальных (возможно даже для частного случая) примитивах (например, точках и/или векторах). Все твои объекты должны уметь создавать/заполнять такие объекты (назовём их регионы), ну а алгоритмы пересечения нужно делать уже для регионов.

A>Ну так просто не получится! Точки здесь не помогут, потомму что у любого региона их континум. Здесь будут сильно отличающиеся друг от друга механизмы хранения того или иного объекта, в том-то и дело.

Точки я привёл к примеру. Главное найти универсальный набор примитивов. Может быть получится взять за основу подход принятый в метафайлах — хранить и манипулировать последовательностями действий, а не только данными. В общем, речь идёт об универсальном формате представления любых объектов.