) утонула в неизвестно чём, решил высказать свои соображения в новой теме.
Напомню вопрос: "Интересно а как ты квадрат то наследовать будешь? Это вырожденный прямоугольник у которого все стороны равны". Сам вопрос, к слову, есть ни что иное, как "проблема круга и эллипса", и даже есть какие-то потуги разрешения:
— через введение обобщения (Square -> Figure <- Rect);
— через требование неизменности объектов;
— через информационную составляющую (как Rect <- Square так и Square <- Rect (!)_)
— через слияние понятий "Square / Rect";
— и т.д.
Но, что самое интересное, от слова "топология" никто (в смысле: "я не нашёл" ) особо не отталкивается при попытках выдать-объяснить решение. Что, если взглянуть на проблему под "топологическим" углом? Быстро выясняется, что любой простой многоугольник (и даже более того — любая замкнутая кривая без самопересечений) топологически эквивалентен окружности. Интересная наклёвывается иерархия, не находите? Вместо специализации поведения — специализация состояния. На вершине иерархии, в базовом классе — интегральные, вычисляемые, качества фигур (площадь, периметр и т.п.), в потомках — лишь специфичные характеристики (радиус, фокусы, углы и т.п.).
Здравствуйте, Wolverrum, Вы писали:
W>Но, что самое интересное, от слова "топология" никто (в смысле: "я не нашёл" ) особо не отталкивается при попытках выдать-объяснить решение. Что, если взглянуть на проблему под "топологическим" углом? Быстро выясняется, что любой простой многоугольник (и даже более того — любая замкнутая кривая без самопересечений) топологически эквивалентен окружности. Интересная наклёвывается иерархия, не находите? Вместо специализации поведения — специализация состояния. На вершине иерархии, в базовом классе — интегральные, вычисляемые, качества фигур (площадь, периметр и т.п.), в потомках — лишь специфичные характеристики (радиус, фокусы, углы и т.п.).
Нет, если уж воспарять до топологии, то нужно ставить вопрос ребром: что от чего следует наследовать: изотопию от гомотопии или же гомотопию от изотопии?
) утонула в неизвестно чём, решил высказать свои соображения в новой теме.
W>Напомню вопрос: "Интересно а как ты квадрат то наследовать будешь? Это вырожденный прямоугольник у которого все стороны равны". Сам вопрос, к слову, есть ни что иное, как "проблема круга и эллипса", и даже есть какие-то потуги разрешения: W>- через введение обобщения (Square -> Figure <- Rect); W>- через требование неизменности объектов; W>- через информационную составляющую (как Rect <- Square так и Square <- Rect (!)_) W>- через слияние понятий "Square / Rect";
Ошибкой является сама попытка наследовать форму.
В примере с графическими примитивами можно наследовать поведение.
Попробую объяснить, что я имею в виду.
Площадь можно вычислить у замкнутых фигур, но нельзя у полилинии.
Тогда все, кроме полилинии, будут реализовывать интерфейс iHasArea, который может быть описан так:
Затем, все объекты могут перемещаться, поэтому все они наследуют IMovable, который можно реализовать так:
class IMovable
{
public:
virtual void move(int dx, int dy) = 0;
}
А если надо иметь дело с вершинами, то нужно вводить отдельный интерфейс iHasVertexes:
class iHasVertexes
{
public:
virtual size_t getVertexCount() const = 0;
virtual POINT getVertex(size_t i) const = 0;
}
Этот интерфейс будет естественным для полигонов и полилиний, а если его реализовать для окружностей или дуг, то можно будет получать их апроксимированное представление. Однако в этот интерфейс нельзя вносить методы setVertexPos(), addVertex() и прочие модифицирующие, ибо они допустимы не для всех фигур.
А попытка наследовать Square от Rectangle приводит к нарушению LSP.
Есть ситуации похуже — во многих системах в качестве графического примитива может выступать текстовая строка. Вот и попробуй увязать полилинию, дугу, окружность, прямоугольник, полигон и текст в одном интерфейсе.
_____________________
С уважением,
Stanislav V. Zudin
Здравствуйте, Stanislav V. Zudin, Вы писали:
SVZ>Ошибкой является сама попытка наследовать форму.
Прекрасно, что объявился единомышленник. Моя идея как раз и состоит в том, что форма — результат специализации, а не исходное свойство "предка".
SVZ>Затем, все объекты могут перемещаться, поэтому все они наследуют IMovable, который можно реализовать так:
Ну, это предположение больше похоже на косяк вашего мысленного дизайна, особенно учитывая следующее: SVZ>Есть ситуации похуже — во многих системах в качестве графического примитива может выступать текстовая строка. Вот и попробуй увязать полилинию, дугу, окружность, прямоугольник, полигон и текст в одном интерфейсе.
Здравствуйте, Wolverrum, Вы писали: W>Но, что самое интересное, от слова "топология" никто (в смысле: "я не нашёл" ) особо не отталкивается при попытках выдать-объяснить решение. Что, если взглянуть на проблему под "топологическим" углом?
Для начала надо сформулировать проблему. Все сложности у людей — ровно с тем, что они пытаются придумать решение, не имея задачи.
Вот ваш "топологический угол" — он для чего нужен? Какую программу вы хотите написать?
Пока вы не определились с задачей, бессмысленно обсуждать её решения.
Поймите, что все эти споры — это как "что обязательно надо брать в отпуск". И вот одни до хрипоты кричат "загранпаспорт", другие "фонарик", третьи "сноуборд", четвёртые "консервы и спирт".
Вам не кажется, что есть фундаментальные отличия между отпусками на собственной даче, в Анталии, и в горах Тянь-шаня?
Здравствуйте, Wolverrum, Вы писали:
SVZ>>Затем, все объекты могут перемещаться, поэтому все они наследуют IMovable, который можно реализовать так: W>Ну, это предположение больше похоже на косяк вашего мысленного дизайна, особенно учитывая следующее:
А в чем косяк? Я описал не абстрактную задачу, а вполне конкретную, которую мне приходилось решать в нескольких проектах.
В этих проектах все графические примитивы могли перемещаться на заданное смещение.
Если есть решение лучше — делись.
SVZ>>Есть ситуации похуже — во многих системах в качестве графического примитива может выступать текстовая строка. Вот и попробуй увязать полилинию, дугу, окружность, прямоугольник, полигон и текст в одном интерфейсе.
_____________________
С уважением,
Stanislav V. Zudin
Здравствуйте, Sinclair, Вы писали:
S>Пока вы не определились с задачей, бессмысленно обсуждать её решения.
Напомню вопрос W>Напомню вопрос: "Интересно а как ты квадрат то наследовать будешь?
>Поймите, что все эти споры — это как "что обязательно надо брать в отпуск". Вам не кажется, что есть фундаментальные отличия между отпусками на собственной даче, в Анталии, и в горах Тянь-шаня?
Определенно, различия есть. Но ведь есть и сходства? Я, например, попробовал не чистить селёдку с хвоста, и оттолкнуться в рассуждениях от топологических инвариантов (фундаментальных сходств) — и пока что получается то, что не совсем понятно как натягивать на существующие реализации ООП.
Здравствуйте, Wolverrum, Вы писали: W>Напомню вопрос W>>Напомню вопрос: "Интересно а как ты квадрат то наследовать будешь?
Вопрос я помню. А задача-то где? Задачи "отнаследовать квадрат" у вменяемых программистов не бывает.
Вот рассматривалась, к примеру, "задача раскроя". Правда, пропонент ООП как-то затруднился привести обоснование применения наследования фигур в этой задаче, всё время скатываясь на то, что Евклид зачем-то изобрел треугольник, значит и нам надо непременно рожать класс Triangle.
Это — по-прежнему оттого, что мысль постоянно перескакивает с идеи "как провести лето" на сноуборд, несмотря на то, что рассматривается круиз по Атлантике.
W>Определенно, различия есть. Но ведь есть и сходства?
Например, какие?
W>Я, например, попробовал не чистить селёдку с хвоста, и оттолкнуться в рассуждениях от топологических инвариантов (фундаментальных сходств) — и пока что получается то, что не совсем понятно как натягивать на существующие реализации ООП.
Вы со своей селёдкой пока что дошли до буквы К в названии "за передовую магию". Это само по себе ничего не доказывает и не опровергает. Как и у других участников.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Wolverrum, Вы писали:
W>Но, что самое интересное, от слова "топология" никто (в смысле: "я не нашёл" ) особо не отталкивается при попытках выдать-объяснить решение. Что, если взглянуть на проблему под "топологическим" углом? Быстро выясняется, что любой простой многоугольник (и даже более того — любая замкнутая кривая без самопересечений) топологически эквивалентен окружности. Интересная наклёвывается иерархия, не находите? Вместо специализации поведения — специализация состояния. На вершине иерархии, в базовом классе — интегральные, вычисляемые, качества фигур (площадь, периметр и т.п.), в потомках — лишь специфичные характеристики (радиус, фокусы, углы и т.п.).
И ни слова про функциональные требования
Re[2]: Е-е-есть! Есть, таки, истинная ценность! ;)
Здравствуйте, Sinclair, Вы писали:
S>Поймите, что все эти споры — это как "что обязательно надо брать в отпуск". И вот одни до хрипоты кричат "загранпаспорт", другие "фонарик", третьи "сноуборд", четвёртые "консервы и спирт". S>Вам не кажется, что есть фундаментальные отличия между отпусками на собственной даче, в Анталии, и в горах Тянь-шаня?
Так, спокойно. Спирт везде будет уместен! В отличии от загранпаспорта, например. Что таки наводит на всякие философские рассуждения об истинности ценностей
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Ikemefula, Вы писали:
I>И ни слова про функциональные требования
Я понимаю, куда хотелось бы скатиться в обсуждении: к критике общего решения в условиях конкретных требований. Удобно, не спорю. Сам хочу
Re[3]: Е-е-есть! Есть, таки, истинная ценность! ;)
Здравствуйте, Erop, Вы писали:
E>Так, спокойно. Спирт везде будет уместен! В отличии от загранпаспорта, например. Что таки наводит на всякие философские рассуждения об истинности ценностей
Во-от! Одежда, кстати, тоже будет везде уместна
Re[4]: Е-е-есть! Есть, таки, истинная ценность! ;)
Здравствуйте, Wolverrum, Вы писали:
W>Во-от! Одежда, кстати, тоже будет везде уместна
Ну немного разная таки...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[5]: Е-е-есть! Есть, таки, истинная ценность! ;)
Здравствуйте, Erop, Вы писали:
W>>Во-от! Одежда, кстати, тоже будет везде уместна E>Ну немного разная таки...
Наследники отпуска будут более конкретными
Здравствуйте, Sinclair, Вы писали:
S> А задача-то где?
Вот присмотрелся я к .NET типам — а там System.Object и отнаследованный от него System.IntPtr. S> Задачи "отнаследовать квадрат" у вменяемых программистов не бывает.
И вот думаю: на задачу ли "отнаследовать квадрат" решали (вменяемые?) разработчики дотнета отнаследовав IntPtr от Object?
Вот, например...
Дано: Замкнутая плоская фигура.
Задача: Рассчитать площадь фигуры.
Требование: Использовать ООП-подход. Расчет не делегировать.
Чем не задача? Выглядит искусственно? Ничуть не более искуственно, чем наследование чего-нибудь от Object (TObject, Any и т.п. — на выбор) при реализации системы типов языка программирования.
W>>Определенно, различия есть. Но ведь есть и сходства? S>Например, какие?
См. ветвь
Здравствуйте, Wolverrum, Вы писали:
W>Дано: Замкнутая плоская фигура. W>Задача: Рассчитать площадь фигуры. W>Требование: Использовать ООП-подход. Расчет не делегировать.
Прошу отметить — Sinclair хотел задачу где возникала бы проблема "круг-овал" и её требовалось бы как-то решать.
Как эта задача соотносилась бы с темой обсуджения — вопрос пока что десятый.
Здравствуйте, Wolverrum, Вы писали: W>Наследники отпуска будут более конкретными
Ну вот видите. Внезапно оказывается, что у нас есть семейство алгоритмов "собраться в отпуск". Конкретные представители этого семейства вполне себе могут наследоваться друг от друга. А вот то, с чем они работают, никакому наследованию не подлежит. Закрытый купальник вовсе не является потомком бикини, как и наоборот.
Программист-идиот может весь на пену изойти, обсуждая вопрос, какой купальник от какого наследовать. Вменяемый программист сначала уточнит задачу: ведь задача кройки ткани для купальника и задача сбора в отпуск ничего общего между собой не имеют.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Wolverrum, Вы писали: W>И вот думаю: на задачу ли "отнаследовать квадрат" решали (вменяемые?) разработчики дотнета отнаследовав IntPtr от Object?
Нет. У них был набор сценариев.
W>Вот, например... W>Дано: Замкнутая плоская фигура. W>Задача: Рассчитать площадь фигуры. W>Требование: Использовать ООП-подход. Расчет не делегировать.
Нет такого требования. W>Чем не задача? Выглядит искусственно? Ничуть не более искуственно, чем наследование чего-нибудь от Object (TObject, Any и т.п. — на выбор) при реализации системы типов языка программирования.
Язык программирования живёт не в вакууме. Невозможно спроектировать язык программирования, не оглядываясь на библиотеки, которые захочется на нём написать. Прекратите упорствовать в заблуждениях
S>>Например, какие? W>См. ветвь
) особо не отталкивается при попытках выдать-объяснить решение. Что, если взглянуть на проблему под "топологическим" углом? Быстро выясняется, что любой простой многоугольник (и даже более того — любая замкнутая кривая без самопересечений) топологически эквивалентен окружности. Интересная наклёвывается иерархия, не находите? Вместо специализации поведения — специализация состояния. На вершине иерархии, в базовом классе — интегральные, вычисляемые, качества фигур (площадь, периметр и т.п.), в потомках — лишь специфичные характеристики (радиус, фокусы, углы и т.п.).
