бгг)

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

не надо, всеравно хрень сделаешь

вопрос то про иерархию типов

как правильно абстракцию выбрать

Только я не вижу разницы с моим и твоим способом хранения - решение было бы одинаковым

Только я не вижу разницы с моим и твоим способом хранения - решение было бы одинаковым

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

вот это больше всего напрягает

interface Measure { public function value(): float; public function unit(): string; } interface Point { public function x(): float; public function y(): float; public function z(): float; } interface Shape { public function width(): Measure; public function height(): Measure; public function coordinates(): Point; } interface FlatShape extends Shape { public function square(): Measure; } interface ThreeDimensionalShape extends Shape { public function depth(): Measure; public function volume(): Measure; }

Фигура устроена сложнее. Она характеризуется количеством граней всех измерений от 0 до n, где n — измерение фигуры. Дальше углами между гранями разных измерений.

И это только про один вид фигур, где есть вообще понятие грани.

И это только про один вид фигур, где есть вообще понятие грани.

А че с окружностью?

Или сферой

Там другие характеристики.

Именно поэтому все попытки выделить абстрактный класс "Фигура" редко увенчиваются успехом

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

Т.е. вписать фигуру в прямоугольник.

Тогда стоит задать только один интерфейс, типа: getMaximumHeight(): float getMaximumWidth(): float И каждую фигуру делать, как отдельный конечный класс со своим набором параметров в конструкторе и реализацией этого интерфейса.

Под "максимальной" шириной имею в виду, например длинну основания треугольника, или диаметр для окружности. А то понятие "ширина" и "максимальная ширина" не четкие.

А то можно квадрат на 45 градусов повернуть и сказать, что диагонали — это его максимальная ширина.

второй день про эти прямоугольники

ну это классика

квадрат vs прямоугольник

и о том как хуево наследование в итоге)

при этом наследование в интерфейсах норм, а вот наследование между объктами надо быть осторожным

все еще не понял, чем моя не подошла и в чем соль

ну так вот, тащемта https://ideone.com/BivRnc

что-то как-то я так и не вижу решения моей задачи с дверями

все еще не понял, чем моя не подошла и в чем соль

соль в том что бы выбирать интерфейсы/ирерахию типов исходя из требуемого поведения а не основываясь на интуиции в духе "ну любой квадртат это прямоугольник"

все еще не понял, чем моя не подошла и в чем соль

тем что там нет объектов)

print('' if result else 'Не', 'Влезает') о - оптимизация)

тем что там нет объектов)

Ну, массив кортежей тоже вполне себе объект)

Зачем здесь вообще интерфейсы и иерархия? Фигура описывается списком ее вершин

Если у вас окружность - ну, апроксимировать ее с какой-то точностью

Зачем здесь вообще интерфейсы и иерархия? Фигура описывается списком ее вершин

Это если она в пространстве.

А дверь у нас не в пространстве?

Зачем здесь вообще интерфейсы и иерархия? Фигура описывается списком ее вершин

с тем, что это простое упражнение на понимание ошибок и вообще работы с созданием иерархий :)

А дверь у нас не в пространстве?

Можно поместить ее в пространство зная ее размеры. Но зачем? Как описать тогда окружность в пространстве?

Зачем? Для решения задачи, зачем же еще

Про окружность уже сказал - апроксимируем.

каждая простая фигура может сообщить о габаритах своей проекции на плоскость под заданным углом, не?

каждая простая фигура может сообщить о габаритах своей проекции на плоскость под заданным углом, не?

Не думаю, что это входит в список ее обязанностей :)

Ну, и это забавно: 1. Берем прямоугольник A x B или откружность радиусом R 2. Помещаем их в пространство, чтобы узнать координаты. 3. Проектируем на плоскость, чтобы узнать габариты.

Ну, массив кортежей тоже вполне себе объект)

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

так че, пора кучи обсужадть чтоль

кучи? ты про хип?

ну

если да то наверное не тот чат)

та да

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

А какое поведение должно быть у фигуры, которая вписывается в дверь?

А какое поведение должно быть у фигуры, которая вписывается в дверь?

isFit

или что-то такое

на ход подаются размеры дверного проема

например

а "форма" сама определяет влезет она или нет

shape.isFitIn(door)

что-то в этом духе

ну можно его завернуть в класс, конечно

суть не измениться

суть в полиморфизме

полиморфизм можно разными способами обеспечить

Логичнее кстати было бы door.IsFittedFor(shape);

shape.isFitIn(door)

Логичнее кстати было бы door.IsFittedFor(shape);

не логичнее

ну или поясни

не, сергей ровно написал

ERROR: S client not available

фигару.посеститьсяВ(дверь)

суть в полиморфизме

который непонятно зачем здесь нужен

Мне кажется, фигура должна инкапсулировать в себе свое состояние. А поведение фигуры - это, ну там, вычислить свою площадь

А вот поведение двери - это уже проверять, влазят ли в не фигуры

ну если фигура должны помещаться только в дверь то серега верно написал. если во все что угодно то можно и shape.isFitIn(someObj)

тоесть дверь это как пример

был

там пиши че хош

ожидай там некий интерфейс и вуаля, полиморфненько

у фигуры тогда появляется собственное действо - понять поместится ли она во чтото

shape.isFitIn(door)

Это ни задача фигуры, ни задача двери — решить, поместится ли фигура в дверь.

я б сказал зависит от ситуации и контекста

нужен менеджер или нет это от задачи

Например, в каком контексте это может быть задача фигуры?

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

Но в этом случае вы создаете зависимость фигуры от двери.

Точнее, вы наделяете фигуру знаниями об интерфейсе двери. Что должно сразу настораживать.

вощем. в 100% случаях менеджера какогонить можно втулить. но это усложнение системы. если система изначально не предполагается что там будет более чем напрмер 3 сущностей то менеджер это скорее излишество чем необходимость, если конечная задача сделать на все случаи жизни то менеджер, если сделать оптимально по трудозатратам то я бы лепил в объектах\интерфейсах кто что может друг у друга проверять

тоесть, вопрос в том разводим ли мы бюрократию или нет

в малых системах нет необходимости, в больших без этого никак

который непонятно зачем здесь нужен

ну в контексте задачи у тебя разные фигуры и от них нужно именно это поведение

вощем. в 100% случаях менеджера какогонить можно втулить. но это усложнение системы. если система изначально не предполагается что там будет более чем напрмер 3 сущностей то менеджер это скорее излишество чем необходимость, если конечная задача сделать на все случаи жизни то менеджер, если сделать оптимально по трудозатратам то я бы лепил в объектах\интерфейсах кто что может друг у друга проверять

менеджеры это раковые опухали и симптомы проблем с декомпозицией

расскажи, как надо?

разделять ответственности по объектам

)

а не заводить "сборник процедур с названием менеджеры"

это вощем можно свести к тому как управлять, вертикаль власти или самоуправление

это вощем можно свести к тому как управлять, вертикаль власти или самоуправление

децентрализация, в этом соль

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

Просто не нужно называть его менеджером.

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

то есть у тебя есть класс "задача"?)

не, это неверно