powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / Программирование [игнор отключен] [закрыт для гостей] / Проектирование классов для C++ приложения
11 сообщений из 11, страница 1 из 1
Проектирование классов для C++ приложения
    #34763404
Serge N
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Столкнулся с проблемой как правильно спроектировать набор классов для приложения C++. Вариантов построения иерархии классов и взаимодействия между ними множество, но выбрать оптимальный мне показалось сложно. Есть ли литература или сайты с информацией, как правильно проектировать набор классов для приложения? Как называется эта отрасль знаний? Слышал про BpWin, Rational Rose. Какой программой лучше пользоваться для проектирования классов для графического редактора, но главный вопрос - как проектировать?
...
Рейтинг: 0 / 0
Проектирование классов для C++ приложения
    #34764791
Фотография fixxer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Отрасль знаний называется "Объектно-ориентированный анализ и проектирование". Для начала ознакомиться с одноименной книжкой Гради Буча. Ответ на "главный" вопрос - головой.
...
Рейтинг: 0 / 0
Проектирование классов для C++ приложения
    #34766138
grieg
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Эта область называется паттерны проектирования.

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

Рисовать классы можно еще, например, в Visio.

Можешь более конкретно задачу?
...
Рейтинг: 0 / 0
Проектирование классов для C++ приложения
    #34772748
kolobok0
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
griegЭта область называется паттерны проектирования.

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

Рисовать классы можно еще, например, в Visio.

Можешь более конкретно задачу?

Выше правильно сказали...
Сначало было слово..тьху Гради Буч...а потом все патерны - хренаторны и прочая шалупонь которая навела тень на плетень


удачи Вам
(круглый)
...
Рейтинг: 0 / 0
Проектирование классов для C++ приложения
    #34773726
Serge N
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
griegЭта область называется паттерны проектирования.

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

Рисовать классы можно еще, например, в Visio.

Можешь более конкретно задачу?

Конкретно - программа показа большого графического изображения.
Есть область на форме, где это изображение показывается.
Есть небольшая панелька - навигатор с уменьшенной до thumbnail копией изображения.
Видимая на экране часть изображения в навигаторе подсвечена красным прямоугольником (как в фотошоп). Кликая по навигатору, можно менять видимую на форме область. И перетаскивая полосы прокрутки области на форме также можно двигаться по изображению. Также можно приближать/удалять - при этом видимая область также меняется.

У меня проблема с синхронизацией этих двух панелей. Вернее проблему я решил, но то, как решил мне не нравится: при каждом событии, ведущем к изменению видимой области, вызываются методы для приведения всех контролов в новое состояние. Например, сдвинулась полоса прокрутки. Значит нужно поменять прямоугольник в навигаторе - вызывается метод навигатора.
Если наоборот, кликнули по навигатору, он вызывает метод полосы прокрутки для изменения ее положения. И так в каждом месте, где происходит изменение области - вызываются в коде методы всех объектом, которые должны отреагировать на изменение. Причем каждый метод должен отслеживать, вызван он в результате события в другом контроле (значит рассылать изменение по остальным он сейчас не должен), или он вызван как реакция на дейстчие пользователя именно с этим контролом и нужно все остальные контролы известить об изменении.
Это неудобно в том плане, что при добавлении нового контрола, который должен быть в этой связке, нужно просматривать весь код и везде добавлять вызов методов этого контрола. И в самом методе нового контрола перебирать вызов методов для всех уже существующих. Код получается довольно запутанный.

Нет ли более стройного решения этой проблемы, где новый контрол один раз просто бы добавлялся в список, в нем реализовывальсь нужные методы и все?
...
Рейтинг: 0 / 0
Проектирование классов для C++ приложения
    #34773937
Фотография fixxer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
MVC с двумя View?
...
Рейтинг: 0 / 0
Проектирование классов для C++ приложения
    #34774004
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Serge NНет ли более стройного решения этой проблемы, где новый контрол один раз просто бы добавлялся в список, в нем реализовывальсь нужные методы и все?
Есть. Надо реализовать оповещение (в приснопамятных паттернах это называется кажется ктототам/subscriber). Человеческими словами это описывается так: делается объект "событие". Кто угодно может подписаться на оповещение об этом событии (зарегистрировать свой обработчик). Тот, кто реально зафиксировал это событие, дергает объект, передавая ему необходимые параметры, и тот рассылает оповещение по всем подписчикам.

Прелесть этой схемы в том, что каждый "контрол" самодостаточен. При создании он подписался на нужные оповещения, при уничтожении отписался - и все, никто и знать не знает, что какой-то контрол где-то там лежит и что-то делает. Скажем, в твоем примере, пусть будет оповещение "видимая область изменилась". Я могу взять проект и добавить в него статусбар, отражающий в панельке координаты видимой области - и ни изображение, ни навигатор, об этом знать не знают и ведать не ведают. С другой стороны: сделал ты метод Image.SetViewport, дергаешь в нем оповещение - и все; теперь ты можешь сделать например диалог, который позволит явно задать координаты видимой области, и опять же без единой строки кода, без единого упоминания и навигатор, и статусбар подстроятся куда нужно.
...
Рейтинг: 0 / 0
Проектирование классов для C++ приложения
    #34774108
maXmo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
строить MVC с нуля долго и скучно, лучше пойти и почитать готовое решение.
...
Рейтинг: 0 / 0
Проектирование классов для C++ приложения
    #34774283
Serge N
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
softwarer Serge NНет ли более стройного решения этой проблемы, где новый контрол один раз просто бы добавлялся в список, в нем реализовывальсь нужные методы и все?
Есть. Надо реализовать оповещение (в приснопамятных паттернах это называется кажется ктототам/subscriber). Человеческими словами это описывается так: делается объект "событие". Кто угодно может подписаться на оповещение об этом событии (зарегистрировать свой обработчик). Тот, кто реально зафиксировал это событие, дергает объект, передавая ему необходимые параметры, и тот рассылает оповещение по всем подписчикам.

Прелесть этой схемы в том, что каждый "контрол" самодостаточен. При создании он подписался на нужные оповещения, при уничтожении отписался - и все, никто и знать не знает, что какой-то контрол где-то там лежит и что-то делает. Скажем, в твоем примере, пусть будет оповещение "видимая область изменилась". Я могу взять проект и добавить в него статусбар, отражающий в панельке координаты видимой области - и ни изображение, ни навигатор, об этом знать не знают и ведать не ведают. С другой стороны: сделал ты метод Image.SetViewport, дергаешь в нем оповещение - и все; теперь ты можешь сделать например диалог, который позволит явно задать координаты видимой области, и опять же без единой строки кода, без единого упоминания и навигатор, и статусбар подстроятся куда нужно.

А как в таком случае быть с проблемой зацикливания - например, изменилось положение полосы прокрутки, она отправила сигнал, что видимая область поменялась. Но и сама полоса прокрутки подписана на это сообщение - она его получит и поменяет положение вновь. При повторном изменении положения полосы, за счет округлений, может получиться слегка другое значение видимой области, и сообщение уйдет снова. Таким образом получается минимум 2 итерации (а то и больше пока все не устаканится), там, где нужна одна? Я действительно сталкивался с этой проблемой.
...
Рейтинг: 0 / 0
Проектирование классов для C++ приложения
    #34774402
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Serge NА как в таком случае быть с проблемой зацикливания
С моей точки зрения такой проблемы в этом случае нет. То есть - я согласен с тем, что, напрягшись, ее можно запрограммировать, но при том, что я полагаю нормальным стилем кодирования такого не возникает.

Впрочем, если считаете важным, можете, например, в объекте оповещения блокировать повторные возбуждения во время оповещения. Правда, это не спасет от зацикливания вида "вызвали оповещение Б, а то снова вызвало оповещение А".

Serge N- например, изменилось положение полосы прокрутки, она отправила сигнал, что видимая область поменялась. Но и сама полоса прокрутки подписана на это сообщение - она его получит и поменяет положение вновь.
Во-первых, если бы ничто другое не помогало, полоса могла бы проверить отправителя сообщения, удостовериться, что это она и есть и успокоиться.

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

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

Наконец, само по себе "получила оповещение об изменении положения.. начала менять положение.." плохо. Плохо не для полосы прокрутки, а с точки зрения взаимодействия множества разных компонент. Проиллюстрировать это проще всего гипотезой о двух полосах прокрутки, одна из которых округляет вниз, а другая вверх - и каждая из них будет думать, что другая неправа, и возвращать область видимости в "правильное" положение. Проблема тут не столько в зацикливании, сколько в том, что задача просто плохо поставлена; как бы мы ни решили эту коллизию, минимум одна из них не выполнит предписанное. И чтобы этого не было, такие паразитные связки надо давить в зародыше. Если область видимости установлена по некоторым координатам - надо "подстроиться" под это, никуда двигать ее не требуется. Это другой метод и другое событие по сравнению с WM_HSCROLL.
...
Рейтинг: 0 / 0
Проектирование классов для C++ приложения
    #34774667
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
maXmoстроить MVC с нуля долго и скучно, лучше пойти и почитать готовое решение.
Я бы предостерег от переоценки MVC. Это довольно узконаправленное и "неудачное в общем" решение, пихание которого в каждую щель не идет на пользу делу.

Что забавно, довольно часто решения, по факту не являющиеся MVC, объявляются таковыми (точнее - люди, делая MVC и наткнувшись на его минусы, меняют дизайн, но по-прежнему уверены, что в результате получили MVC).
...
Рейтинг: 0 / 0
11 сообщений из 11, страница 1 из 1
Форумы / Программирование [игнор отключен] [закрыт для гостей] / Проектирование классов для C++ приложения
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]