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

Кё>Я ищу примеры классов объектов, которые вызывают трудности при объектном моделировании в современных ЯП типа C++ или C#. В качестве примера, я знаю всего две классические задачи:

Кё>1. Построить иерархию классов для прямоугольника и квадрата, с изменяющимися размерами. Трудность в том, что хотя квадрат всегда является прямоугольником (наследуется), он не захочет наследовать его реализацию (зачем ему раздельно хранить ширину и высоту?). Другая трудность в том, что прямоугольник иногда может являться квадратом, но классические отношения между классами, которые предлагают ЯП (наследование и implicit-conversion) не могут выразить такого отношения.

Кё>2. Комплексное число и вещественное число. Хотя вещественное число является комплексным (наследование), вы не станете наследовать его от комплексного по многим причинам: вам не нужна его реализация (два float в памяти вместо одного), вы вряд ли будете рады тому что sqrt(4) вместо 2.0 вернёт тупл из двух комплексных чисел, и т.п.

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

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


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

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

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

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

Допустим Вы ставите цель: унификация отображения геометрической фигуры.

Тут же Вы понимаете — не нужна Вам никакая иерархия. Все что Вам нужно, это:

interface
{
void draw(TCanvas canvas, RECT rect);
}

Причем это решение вообще не накладывает никаких ограничений на то, что именно рисуется — квадрат, круг или портрет Дориана Грея.

Вот и ответ на Ваш вопрос.

То же рассуждение касается и чисел. Когда Вы пытаетесь неутомимым программистским умом запихнуть в одну конструкцию вещественные и комплексные числа, Вы спросите себя — зачем? Зачем Вам знать сколько там float-ов в вещественном числе? Нет, правда — зачем? Вам беспокоит вопрос унификации хранения разнородных объектов? А почему? Вы хотите их на диск сбрасывать в записи фиксированной длины?

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