Здравствуйте, Wolverrum, Вы писали:
W>Введение в контекст проблемы "квадрат-прямоугольник" третьей сущности "ромб" наглядно показывает всю глубину глубин
Ну вот видите, уже прогресс. А знаете, почему вы наблюдаете то, что наблюдате?
Потому, что наследование классов в ООП — оно не про состояние; общность "свойств" ещё не повод для наследования. Нужно искать общность поведения.
Покуда квадрат, прямоугольник, и ромб никак "себя" не ведут, рассуждать об отношениях наследования нет никакого смысла.
Если отвлечься от геометрии, то внезапно окажется, что квадрат/прямоугольник изоморфны, например, именам людей. То есть понятно, что бывают Иваны Алексеевичи, а бывают Иваны Ивановичи и Алексеи Алексеевичи. Но почему-то никто не бросается немедленно выделять отдельный класс людей с такими совпадениями, и мучиться выбором иерархии наследования.
Нет никакой нужды выделять в отдельный класс людей, фамилии которых начинаются на букву И. А ведь предикат StartsWithI(person p) {return p.LastName[0] == 'I';} ничуть не хуже предиката IsRightTriangle(Trianle t) { return t.AngleValues.HasAny(a => a==Math.PI/2);}.
Ну так за каким хреном внезапно хочется делать класс RightTriangle, если желания ввести класс PersonNamedStartingWithI не возникает?
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Wolverrum, Вы писали: W>Но, что самое интересное, от слова "топология" никто (в смысле: "я не нашёл" ) особо не отталкивается при попытках выдать-объяснить решение. Что, если взглянуть на проблему под "топологическим" углом?
Для начала надо сформулировать проблему. Все сложности у людей — ровно с тем, что они пытаются придумать решение, не имея задачи.
Вот ваш "топологический угол" — он для чего нужен? Какую программу вы хотите написать?
Пока вы не определились с задачей, бессмысленно обсуждать её решения.
Поймите, что все эти споры — это как "что обязательно надо брать в отпуск". И вот одни до хрипоты кричат "загранпаспорт", другие "фонарик", третьи "сноуборд", четвёртые "консервы и спирт".
Вам не кажется, что есть фундаментальные отличия между отпусками на собственной даче, в Анталии, и в горах Тянь-шаня?
Здравствуйте, Wolverrum, Вы писали: W>Напомню вопрос W>>Напомню вопрос: "Интересно а как ты квадрат то наследовать будешь?
Вопрос я помню. А задача-то где? Задачи "отнаследовать квадрат" у вменяемых программистов не бывает.
Вот рассматривалась, к примеру, "задача раскроя". Правда, пропонент ООП как-то затруднился привести обоснование применения наследования фигур в этой задаче, всё время скатываясь на то, что Евклид зачем-то изобрел треугольник, значит и нам надо непременно рожать класс Triangle.
Это — по-прежнему оттого, что мысль постоянно перескакивает с идеи "как провести лето" на сноуборд, несмотря на то, что рассматривается круиз по Атлантике.
W>Определенно, различия есть. Но ведь есть и сходства?
Например, какие?
W>Я, например, попробовал не чистить селёдку с хвоста, и оттолкнуться в рассуждениях от топологических инвариантов (фундаментальных сходств) — и пока что получается то, что не совсем понятно как натягивать на существующие реализации ООП.
Вы со своей селёдкой пока что дошли до буквы К в названии "за передовую магию". Это само по себе ничего не доказывает и не опровергает. Как и у других участников.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
) утонула в неизвестно чём, решил высказать свои соображения в новой теме.
Напомню вопрос: "Интересно а как ты квадрат то наследовать будешь? Это вырожденный прямоугольник у которого все стороны равны". Сам вопрос, к слову, есть ни что иное, как "проблема круга и эллипса", и даже есть какие-то потуги разрешения:
— через введение обобщения (Square -> Figure <- Rect);
— через требование неизменности объектов;
— через информационную составляющую (как Rect <- Square так и Square <- Rect (!)_)
— через слияние понятий "Square / Rect";
— и т.д.
Но, что самое интересное, от слова "топология" никто (в смысле: "я не нашёл" ) особо не отталкивается при попытках выдать-объяснить решение. Что, если взглянуть на проблему под "топологическим" углом? Быстро выясняется, что любой простой многоугольник (и даже более того — любая замкнутая кривая без самопересечений) топологически эквивалентен окружности. Интересная наклёвывается иерархия, не находите? Вместо специализации поведения — специализация состояния. На вершине иерархии, в базовом классе — интегральные, вычисляемые, качества фигур (площадь, периметр и т.п.), в потомках — лишь специфичные характеристики (радиус, фокусы, углы и т.п.).
Здравствуйте, Wolverrum, Вы писали:
W>Здравствуйте, Wolverrum, Вы писали:
W>>Дано: Замкнутая плоская фигура. W>>Задача: Рассчитать площадь фигуры. W>>Требование: Использовать ООП-подход. Расчет не делегировать. W>Прошу отметить — Sinclair хотел задачу где возникала бы проблема "круг-овал" и её требовалось бы как-то решать.
Вы что, серъезно полагаете, что в вашей "задаче" возникла проблема "круг-овал"???
ОМГ, ОМГ, ОМГ.
Ну давайте поиграем. Вы будете выступать на стороне некомпетентного заказчика, я — исполнителя. Некомпететного — потому, что вы пытаетесь лезть в обязанности исполнителя (скажем, в выбор технологии и подхода), усердно забывая про свою часть работы — требования.
Вы свой ход сделали. Вот мой ход:
— что вы называете "фигурой"? Какие виды фигур вы хотите поддерживать? Откуда берутся экземпляры фигур?
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Wolverrum, Вы писали:
W>Но, что самое интересное, от слова "топология" никто (в смысле: "я не нашёл" ) особо не отталкивается при попытках выдать-объяснить решение. Что, если взглянуть на проблему под "топологическим" углом? Быстро выясняется, что любой простой многоугольник (и даже более того — любая замкнутая кривая без самопересечений) топологически эквивалентен окружности. Интересная наклёвывается иерархия, не находите? Вместо специализации поведения — специализация состояния. На вершине иерархии, в базовом классе — интегральные, вычисляемые, качества фигур (площадь, периметр и т.п.), в потомках — лишь специфичные характеристики (радиус, фокусы, углы и т.п.).
Здравствуйте, Wolverrum, Вы писали:
W>Здравствуйте, Ikemefula, Вы писали:
I>>И ни слова про функциональные требования W>Я понимаю, куда хотелось бы скатиться в обсуждении: к критике общего решения в условиях конкретных требований. Удобно, не спорю. Сам хочу
Видишь ли, без сформулированной задачи вопрос, что от чего наследовать, аналогичен вопросу, что лучше делать с числами — складывать или умножать.
Потому что ответ, очевидно, будет такой: а чего ты хочешь-то в результате? Просто чтоб был какой-то значок между двумя числами? Или тебе таки ехать, а не шашечки?
Здравствуйте, Erop, Вы писали:
W>>Во-от! Одежда, кстати, тоже будет везде уместна E>Ну немного разная таки...
Наследники отпуска будут более конкретными
Здравствуйте, Wolverrum, Вы писали:
W>Дано: Замкнутая плоская фигура. W>Задача: Рассчитать площадь фигуры. W>Требование: Использовать ООП-подход. Расчет не делегировать.
Прошу отметить — Sinclair хотел задачу где возникала бы проблема "круг-овал" и её требовалось бы как-то решать.
Как эта задача соотносилась бы с темой обсуджения — вопрос пока что десятый.
Здравствуйте, Wolverrum, Вы писали: W>Наследники отпуска будут более конкретными
Ну вот видите. Внезапно оказывается, что у нас есть семейство алгоритмов "собраться в отпуск". Конкретные представители этого семейства вполне себе могут наследоваться друг от друга. А вот то, с чем они работают, никакому наследованию не подлежит. Закрытый купальник вовсе не является потомком бикини, как и наоборот.
Программист-идиот может весь на пену изойти, обсуждая вопрос, какой купальник от какого наследовать. Вменяемый программист сначала уточнит задачу: ведь задача кройки ткани для купальника и задача сбора в отпуск ничего общего между собой не имеют.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Wolverrum, Вы писали: W>И вот думаю: на задачу ли "отнаследовать квадрат" решали (вменяемые?) разработчики дотнета отнаследовав IntPtr от Object?
Нет. У них был набор сценариев.
W>Вот, например... W>Дано: Замкнутая плоская фигура. W>Задача: Рассчитать площадь фигуры. W>Требование: Использовать ООП-подход. Расчет не делегировать.
Нет такого требования. W>Чем не задача? Выглядит искусственно? Ничуть не более искуственно, чем наследование чего-нибудь от Object (TObject, Any и т.п. — на выбор) при реализации системы типов языка программирования.
Язык программирования живёт не в вакууме. Невозможно спроектировать язык программирования, не оглядываясь на библиотеки, которые захочется на нём написать. Прекратите упорствовать в заблуждениях
S>>Например, какие? W>См. ветвь
Здравствуйте, Wolverrum, Вы писали:
I>>И ни слова про функциональные требования W>Я понимаю, куда хотелось бы скатиться в обсуждении: к критике общего решения в условиях конкретных требований. Удобно, не спорю. Сам хочу
Без функциональных требований любой дизайн не имеет смысла. Наследуй квадрат хоть от треугольника, хоть от Application, хоть от StringBuilder разницы абсолютно никакой.
Здравствуйте, 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, Вы писали:
SVZ>>Затем, все объекты могут перемещаться, поэтому все они наследуют IMovable, который можно реализовать так: W>Ну, это предположение больше похоже на косяк вашего мысленного дизайна, особенно учитывая следующее:
А в чем косяк? Я описал не абстрактную задачу, а вполне конкретную, которую мне приходилось решать в нескольких проектах.
В этих проектах все графические примитивы могли перемещаться на заданное смещение.
Если есть решение лучше — делись.
SVZ>>Есть ситуации похуже — во многих системах в качестве графического примитива может выступать текстовая строка. Вот и попробуй увязать полилинию, дугу, окружность, прямоугольник, полигон и текст в одном интерфейсе.
_____________________
С уважением,
Stanislav V. Zudin
Здравствуйте, Sinclair, Вы писали:
S>Пока вы не определились с задачей, бессмысленно обсуждать её решения.
Напомню вопрос W>Напомню вопрос: "Интересно а как ты квадрат то наследовать будешь?
>Поймите, что все эти споры — это как "что обязательно надо брать в отпуск". Вам не кажется, что есть фундаментальные отличия между отпусками на собственной даче, в Анталии, и в горах Тянь-шаня?
Определенно, различия есть. Но ведь есть и сходства? Я, например, попробовал не чистить селёдку с хвоста, и оттолкнуться в рассуждениях от топологических инвариантов (фундаментальных сходств) — и пока что получается то, что не совсем понятно как натягивать на существующие реализации ООП.
Re[2]: Е-е-есть! Есть, таки, истинная ценность! ;)
Здравствуйте, Sinclair, Вы писали:
S>Поймите, что все эти споры — это как "что обязательно надо брать в отпуск". И вот одни до хрипоты кричат "загранпаспорт", другие "фонарик", третьи "сноуборд", четвёртые "консервы и спирт". S>Вам не кажется, что есть фундаментальные отличия между отпусками на собственной даче, в Анталии, и в горах Тянь-шаня?
Так, спокойно. Спирт везде будет уместен! В отличии от загранпаспорта, например. Что таки наводит на всякие философские рассуждения об истинности ценностей
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Ikemefula, Вы писали:
I>И ни слова про функциональные требования
Я понимаю, куда хотелось бы скатиться в обсуждении: к критике общего решения в условиях конкретных требований. Удобно, не спорю. Сам хочу
Re[3]: Е-е-есть! Есть, таки, истинная ценность! ;)
Здравствуйте, Erop, Вы писали:
E>Так, спокойно. Спирт везде будет уместен! В отличии от загранпаспорта, например. Что таки наводит на всякие философские рассуждения об истинности ценностей
Во-от! Одежда, кстати, тоже будет везде уместна
Re[4]: Е-е-есть! Есть, таки, истинная ценность! ;)
Здравствуйте, Wolverrum, Вы писали:
W>Во-от! Одежда, кстати, тоже будет везде уместна
Ну немного разная таки...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Sinclair, Вы писали:
S> А задача-то где?
Вот присмотрелся я к .NET типам — а там System.Object и отнаследованный от него System.IntPtr. S> Задачи "отнаследовать квадрат" у вменяемых программистов не бывает.
И вот думаю: на задачу ли "отнаследовать квадрат" решали (вменяемые?) разработчики дотнета отнаследовав IntPtr от Object?
Вот, например...
Дано: Замкнутая плоская фигура.
Задача: Рассчитать площадь фигуры.
Требование: Использовать ООП-подход. Расчет не делегировать.
Чем не задача? Выглядит искусственно? Ничуть не более искуственно, чем наследование чего-нибудь от Object (TObject, Any и т.п. — на выбор) при реализации системы типов языка программирования.
W>>Определенно, различия есть. Но ведь есть и сходства? S>Например, какие?
См. ветвь
Здравствуйте, Wolverrum, Вы писали: I>>И ни слова про функциональные требования W>Я понимаю, куда хотелось бы скатиться в обсуждении: к критике общего решения в условиях конкретных требований. Удобно, не спорю. Сам хочу
Неа. Хочется перейти к критике поиска общего решения в условиях отсутствия конкретных требований.
Поймите наконец, что в отрыве от требований нельзя вообще говорить об адекватности или неадекватности решения.
Практически под любое, самое экзотическое, решение можно подсунуть требования задним числом так, чтобы решение внезапно оказалось адекватным.
Этот вид реверс-инжиниринга, т.е. попытка воссоздать требования по продиктованному ими дизайну, является хорошим мысленным упражнением.
Но вы и им отказываетесь заниматься. По непонятной лично мне причине.
Если вам непонятна моя аллегория с отпуском, я могу предложить более другую: давайте решим, что лучше — соль или сахар. При этом будем всеми силами отказываться обсуждать конкретную задачу, потому что хочется непременно получить общее решение. А ваша позиция — примерно такова: почему никто не удосужился рассмотреть проблему соль/сахар под углом стирального порошка? Нет-нет-нет, не скатывайтесь к критике этого общего решения в условиях конкретных требований по засолке рыбы.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
наследование имеет смысл когда мы имеем с действительно производными сущностными. скажем, есть у нас абстрактный объект. это может быть и файл, и блок памяти, и база данных, управляемая через web-сервис. и теперь нам нужен абстрактный объект, но только сжатый. и тут вылезают тонкости. перегонять базу по сети, жать на клиенте, и расжимать -- дурость. пусть она предоставляет методы, которые отрабатывают на сервере.
затем мы наследуем от этого объекта абстрактный файл с прозрачным сжатием и если он у нас на диске -- жмем локально, если нет -- то на сервере.
при этом сохраняется возможность унаследовать абстрактный файл непосредственно от абстрактного объекта, минуя стадию сжатия.
а фигуры это плохой пример. хотя если все фигуры унаследованы от общего предка, то они все поддерживают унифиированный набор методов типа разворота, но у разных фигур и реализация разная. у круга она вообще вырождается.
короче, язык дает вам средство выражения. пользуйтесь им с умом и профитом. и не следуйте рекомендациям теоретиков, а то ведь при составлении резюме на английском всячески рекомендуют избегать пассивного залога. вот только сказать "я родился и вырос" в активном залоге... это же нужно хорошо покурить.
americans fought a war for a freedom. another one to end slavery. so, what do some of them choose to do with their freedom? become slaves.
