Здравствуйте, Wolverrum, Вы писали:
W>Здравствуйте, Wolverrum, Вы писали:
W>>Дано: Замкнутая плоская фигура. W>>Задача: Рассчитать площадь фигуры. W>>Требование: Использовать ООП-подход. Расчет не делегировать. W>Прошу отметить — Sinclair хотел задачу где возникала бы проблема "круг-овал" и её требовалось бы как-то решать.
Вы что, серъезно полагаете, что в вашей "задаче" возникла проблема "круг-овал"???
ОМГ, ОМГ, ОМГ.
Ну давайте поиграем. Вы будете выступать на стороне некомпетентного заказчика, я — исполнителя. Некомпететного — потому, что вы пытаетесь лезть в обязанности исполнителя (скажем, в выбор технологии и подхода), усердно забывая про свою часть работы — требования.
Вы свой ход сделали. Вот мой ход:
— что вы называете "фигурой"? Какие виды фигур вы хотите поддерживать? Откуда берутся экземпляры фигур?
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Wolverrum, Вы писали:
W>Здравствуйте, Ikemefula, Вы писали:
I>>И ни слова про функциональные требования W>Я понимаю, куда хотелось бы скатиться в обсуждении: к критике общего решения в условиях конкретных требований. Удобно, не спорю. Сам хочу
Видишь ли, без сформулированной задачи вопрос, что от чего наследовать, аналогичен вопросу, что лучше делать с числами — складывать или умножать.
Потому что ответ, очевидно, будет такой: а чего ты хочешь-то в результате? Просто чтоб был какой-то значок между двумя числами? Или тебе таки ехать, а не шашечки?
Здравствуйте, Wolverrum, Вы писали: I>>И ни слова про функциональные требования W>Я понимаю, куда хотелось бы скатиться в обсуждении: к критике общего решения в условиях конкретных требований. Удобно, не спорю. Сам хочу
Неа. Хочется перейти к критике поиска общего решения в условиях отсутствия конкретных требований.
Поймите наконец, что в отрыве от требований нельзя вообще говорить об адекватности или неадекватности решения.
Практически под любое, самое экзотическое, решение можно подсунуть требования задним числом так, чтобы решение внезапно оказалось адекватным.
Этот вид реверс-инжиниринга, т.е. попытка воссоздать требования по продиктованному ими дизайну, является хорошим мысленным упражнением.
Но вы и им отказываетесь заниматься. По непонятной лично мне причине.
Если вам непонятна моя аллегория с отпуском, я могу предложить более другую: давайте решим, что лучше — соль или сахар. При этом будем всеми силами отказываться обсуждать конкретную задачу, потому что хочется непременно получить общее решение. А ваша позиция — примерно такова: почему никто не удосужился рассмотреть проблему соль/сахар под углом стирального порошка? Нет-нет-нет, не скатывайтесь к критике этого общего решения в условиях конкретных требований по засолке рыбы.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Wolverrum, Вы писали:
W>Введение в контекст проблемы "квадрат-прямоугольник" третьей сущности "ромб" наглядно показывает всю глубину глубин
Ну вот видите, уже прогресс. А знаете, почему вы наблюдаете то, что наблюдате?
Потому, что наследование классов в ООП — оно не про состояние; общность "свойств" ещё не повод для наследования. Нужно искать общность поведения.
Покуда квадрат, прямоугольник, и ромб никак "себя" не ведут, рассуждать об отношениях наследования нет никакого смысла.
Если отвлечься от геометрии, то внезапно окажется, что квадрат/прямоугольник изоморфны, например, именам людей. То есть понятно, что бывают Иваны Алексеевичи, а бывают Иваны Ивановичи и Алексеи Алексеевичи. Но почему-то никто не бросается немедленно выделять отдельный класс людей с такими совпадениями, и мучиться выбором иерархии наследования.
Нет никакой нужды выделять в отдельный класс людей, фамилии которых начинаются на букву И. А ведь предикат StartsWithI(person p) {return p.LastName[0] == 'I';} ничуть не хуже предиката IsRightTriangle(Trianle t) { return t.AngleValues.HasAny(a => a==Math.PI/2);}.
Ну так за каким хреном внезапно хочется делать класс RightTriangle, если желания ввести класс PersonNamedStartingWithI не возникает?
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
наследование имеет смысл когда мы имеем с действительно производными сущностными. скажем, есть у нас абстрактный объект. это может быть и файл, и блок памяти, и база данных, управляемая через 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.
Здравствуйте, Wolverrum, Вы писали:
I>>И ни слова про функциональные требования W>Я понимаю, куда хотелось бы скатиться в обсуждении: к критике общего решения в условиях конкретных требований. Удобно, не спорю. Сам хочу
Без функциональных требований любой дизайн не имеет смысла. Наследуй квадрат хоть от треугольника, хоть от Application, хоть от StringBuilder разницы абсолютно никакой.
