Задача про контейнеры в контейнере и их размеры

[Antonshka]

Приветствую снова, если у кого есть желание, помогите с решение такой задачи (сам я никак не могу решить, сколько дней не пробовал, или недель уже)

Есть внешний контейнер, размеров 35 см. В нем содержатся три внутренних контейнера, 5, 10, 20 см. Каждый внутренний контейнер примыкает к своему соседу вплотную. Отчет "X" позиции ведется от левого края внешнего контейнера , от 0.

Вопрос 1

Как рассчитать размер каждого внутреннего контейнера, после того как их внешний контейнер уменьшиться почти в два раза (станет равным 15 , вместо 35 см.)?

Внутренние контейнеры должны уменьшаться равномерно, то есть должны стать 2.5, 5, 10 см.

Вопрос 2

Если уменьшить внутренний контейнер 10 см. до размера 3 см. то как сохранить размеры остальных двух (5 и 20 см.) и сохранить плотное примыкание к друг другу.

Вопрос 3

Если между контейнером 10 см. и 20 см вставить еще один контейнер (пусть 17 см), то как изменится отношении внутренних и внешнего контейнеров?

 

Вот изображение контейнеров

Спойлер

 

 

Изменено 11 марта, 2022 пользователем Antonshka

[Antonshka]

Вопрос 2 был составлен не правильно, вот как правильно

Если уменьшить внутренний контейнер 10 см. до размера 3 см. а внутренний контейнер 20 см увеличить на 7...

То есть по идее общая ширина не измениться. Так что ответ на этот вопрос и не нужен.

Изменено 11 марта, 2022 пользователем Antonshka

[Xipho]

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

[Antonshka]

10 часов назад, Xipho сказал:

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

Хороший вариант, что-то подобное мне тоже пришло на ум, когда я оформил этот пост. Но пока я не публиковал его, тестирую.

Я делаю Docking систему, как в Microsoft Visual Studio.

Удержать в голове все моменты, или даже хотя бы алгоритмы, никак не удается. Все смешивается, слишком много взаимодействий и зависимостей одних элементов системы от других. Но тем интереснее.

 

Сейчас я делаю таким алгоритмом,

- после добавления нового внутреннего контейнера во внешний контейнер, ширина внешнего контейнера увеличивается на ширину нового добавленного контейнера

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

5 / 35 = ...

10 / 35 = ...

20 / 35 = ...

- новому добавленному контейнеру назначается его левый сосед, точнее правый край левого соседа, чтобы он был началом его X позиции

- и еще много чего другого

Вся система строится на произвольном дереве.

[Xipho]

Вопрос не совсем по теме, скорее где-то сбоку. Ты говоришь, много алгоритмов, сложно в голове удержать. А такой вопрос - ты какими паттернами проектирования кода пользуешься? Просто задачи, описываемые тобой выглядят как подпадающие под несколько паттернов, которые сильно облегчают разработку и сопровождение. Например, "слишком много взаимодействий и зависимостей" укладываются в концепцию паттернов "Стратегия", "Посетитель", "Наблюдатель". 

[Antonshka]

44 минуты назад, Xipho сказал:

Вопрос не совсем по теме, скорее где-то сбоку. Ты говоришь, много алгоритмов, сложно в голове удержать. А такой вопрос - ты какими паттернами проектирования кода пользуешься? Просто задачи, описываемые тобой выглядят как подпадающие под несколько паттернов, которые сильно облегчают разработку и сопровождение. Например, "слишком много взаимодействий и зависимостей" укладываются в концепцию паттернов "Стратегия", "Посетитель", "Наблюдатель". 

Первый раз слышу о паттернах проектирования. Я писал просто, не задумываясь над этим.

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

 

Я делал так, - есть какой-то С++ класс, например класс простого окна. В этом классе есть поля, являющиеся объектами других классов, которые каким-то образом влияют на само окно, на сам класс класс окна, или на другие поля-объекты этого класса окна.

 

Использую там где нужно "friend" для классов и их полей, объектов других классов.

 

[Xipho]

2 часа назад, Antonshka сказал:

Первый раз слышу о паттернах проектирования

Настоятельно рекомендую к незамедлительному прочтению вот эти две книги:

 

Спойлер

 

Спойлер

 

 

В первой примеры на Java, но очень хорошо описаны, потому сам язык не является препятствием в понимании концепций.

[Antonshka]

4 часа назад, Xipho сказал:

Настоятельно рекомендую к незамедлительному прочтению вот эти две книги:

 

  Показать контент

 

  Показать контент

 

 

В первой примеры на Java, но очень хорошо описаны, потому сам язык не является препятствием в понимании концепций.

Спасибо, а то википедия как обычно все "усложняет". Судя по тому как описано в ней, и на этом сайте, который я сегодня нашел.

Спойлер

https://refactoring.guru/ru/design-patterns/visitor

 

Я прочитал еще где-то в другом месте что следование таким шаблонам имеет и свои минусы, как и плюсы.

Думаю доделаю эту Docking систему, и возьму паузу. Почитаю про шаблоны.

[Xipho]

5 часов назад, Antonshka сказал:

Думаю доделаю эту Docking систему, и возьму паузу. Почитаю про шаблоны.

Рекомендую не откладывать, и сначала почитать. Даю процентов 80 на то, что это позволит тебе лучше и быстрее  реализовать систему докинга (да и весь твой фреймворк). Есть ещё книги дядюшки Боба (Роберт Мартин) "Чистый код" и "Чистая архитектура". Опять же, первая с примерами на Java, но концепции доносятся достаточно понятно. Без базиса с паттернами проектирования и понимания написания чистого и сопровождаемого кода и особенностей архитектуры ПО, имхо, браться за написание фреймворка не стоит от слова "совсем". Будешь постоянно наступать сам себе на пятки, и это превратится в бесконечный рефакторинг. Браться без вышеописанного базиса не стоит за ПО сложнее трейнми или простеньких окошек. Разумеется, это все мое скромное мнение, к которому я пришел через опыт в разработке, походив по изрядному количеству граблей.

Кстати, refactoring.guru - хороший сайт, но описание паттернов мне там не понравилось. В книгах, что я выше написал по паттернам, суть раскрывается намного лучше.

[Antonshka]

10 часов назад, Xipho сказал:

Рекомендую не откладывать, и сначала почитать. Даю процентов 80 на то, что это позволит тебе лучше и быстрее  реализовать систему докинга (да и весь твой фреймворк). Есть ещё книги дядюшки Боба (Роберт Мартин) "Чистый код" и "Чистая архитектура". Опять же, первая с примерами на Java, но концепции доносятся достаточно понятно. Без базиса с паттернами проектирования и понимания написания чистого и сопровождаемого кода и особенностей архитектуры ПО, имхо, браться за написание фреймворка не стоит от слова "совсем". Будешь постоянно наступать сам себе на пятки, и это превратится в бесконечный рефакторинг. Браться без вышеописанного базиса не стоит за ПО сложнее трейнми или простеньких окошек. Разумеется, это все мое скромное мнение, к которому я пришел через опыт в разработке, походив по изрядному количеству граблей.

Кстати, refactoring.guru - хороший сайт, но описание паттернов мне там не понравилось. В книгах, что я выше написал по паттернам, суть раскрывается намного лучше.

Я согласен, нужно строить с фундамента и выше. Но мне в данном случае осталось немного, хочу набросать хотя бы сырой, но работающий код Docking системы. Успокоится, что основа ее готова, протестирована, и сохранена.