Вопрос по ООПООП?

Question

[oandrew]

Пишу приложение и не могу понять как правильно сделать.

Есть классы Page и PageHandler.

class Page {
    int x,y,height, width;
    ...
}

class PageHandler {
    vector<Page> pages;
    ...
}

Собственно PageHandler инкапсулирует набор страниц.

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

А значит, если уменьшаем высоту страницы на 50 px, то все нижестоящие страницы нужно подвинуть вверх на 50 px.


Вопрос: кто должен отвечать за такой функционал?

Если PageHandler, тогда нужно запретить прямой доступ к Page и делать все операции только через PageHandler?


Или как логичней?

П.С.

Пришел в голову еще вариант. Если нужно — просто меняем размер страницы. А дальше запускаем метод PageHandler::updatePositions() который пробежится по всем страницам и пересчитает x, y координаты.

Только и тут вопрос — в каком методе это делать — PageHandler::setSize(int page,int width,int height) или Page::setSize(int width, int height). Во втором придется хранить ссылку на PageHandler что бы запустить updatePositions().

Comments

[niko83]

не понятно выражение «Собственно PageHandler инкапсулирует набор страниц.»
Инкапсуляция в моём понимани это сокрытие реализации и предоставление для пользования какого-то определённого интерфейса для работы.

Answer 1

[Rafael Osipov]

На мой взгляд PageHandler не совсем удачный термин. Я бы выбрал Book.

Который содержит в себе Pages.

Так как размер страницы не может быть больше размера книги (хотя и бывают редкие забавные исключения), то размер страницы храним в Book, а не в Page.

Добавляя страницу в Book мы передаём ей размер, в который она должна «втиснуться».

Отвечать за функционал смещения страниц книги при изменении размера страницы должен отвечать класс BookView, если говорить в терминологии Model-View-Controller.

Экземпляр которого, в свою очередь, посылает сообщение всем экземплярам класса PageView, что размеры теперь другие.

Comments

[oandrew]

Вот у меня как раз забавное исключение — я пишу приложение просмотра djvu и pdf файлов на моб. платформу ) Так что больше даже Document.

По этому каждая страница может иметь свои размеры.

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

Answer 2

[lalaki]

x,y — не свойства самой страницы как элемента данных, а свойства представления конкретной страницы, к тому же, вычисляемые:

в общее представление, условно «ленту страниц», передается порядок следования страниц, а оно по их размерам вычисляет расположение.

поэтому отдельно должно быть изменение размера страницы — в самой странице, отдельно — изменение расположения — в представлении, при этом они должны быть связаны.

Вариантов много, простейший и универсальный для MVC: «1) изменить данные; 2) обновить представление»: вызывается сначала изменение размера страницы, затем — перерисовка представления, каждый делает свое.

Можно покопать аналогичные элементы интерфейса в разных языках и библиотеках — посмотреть, как там, т.к. задача типовая.

Answer 3

[int02h]

Уж точно не страницы должны себя двигать.
Я бы реализовал требуемую логику в PageHandler путем реализации метода (собственно как Вы сами и предложили) updatePositions(). То есть Вы меняется размеры страницы, а затем вызываете указанный метод. Если Вам не нравиться прямой доступ к страницам, то можно функционал изменения параметров страниц вынести в PageHandler. Например:

pageHandler->setPageSize(int pageIndex, Size size);

Как-то так.