описание внутренней архитектуры программы
Автор: Hunter
Дата: 14.06.2009 21:18
Программа писалась в несколько этапов. Сначала это был любительский проект, попытка написать чат, внешне похожий на Intranet Chat. По мере совершенствования возникали новые сложности и приходилось менять архитектуру программы.
Раньше ядра как такового не было - была основная форма, на которой лежали все визуальные и невизуальные объекты (кроме отдельных окошек). При создании новой страницы чата эта страница программно собиралась из составляющих объектов. Страницы идентифицировались по заголовку, т.е. две страницы с одинаковыми заголовками уже не работали. Обращение к объектам на странице происходило напрямую. Т.е. для добавления юзера в список юзеров нужно было найти нужную страницу, и обратиться прямо к визуальному списку, который на ней лежит.
Со временем добавились новые типы страниц - список каналов, список файлов. Обращение к их элементам усложнилось, нужно было проверять тип страницы. При всяком изменении страницы приходилось искать по всей программе обращения к элементам страницы и исправлять их. И вообще структура была запутана, но все это как-то работало.. Но расширять функционал и добавлять новые фичи было очень сложно.
Сейчас функционал поделен на несколько основных частей:
В начале все страницы настроек создавались программно, сами настройки хранились прямо в визуальных элементах (контролах) формы. Просто, относительно удобно, но нельзя реализовать, к примеру, отмену изменений конфига.
Потом настройки были реализованы как свойства отдельного автономного объекта (конфига), а их визуальное представление в виде отдельных панелей было создано заранее и свалено в одну кучу. Стало удобнее, но такой конфиг прописан в коде программы, его нельзя расширить во время работы программы.
Сейчас конфиг реализован по образу и подобию виндового реестра (то есть позволяет хранить одинаковые наборы данных в разных ветках), веткам можно назначать страницу визуальных элементов (контролов), сами страницы настроек не валяются как попало, а сидят на невидимых закладках. Есть универсальная страница настроек, в виде списка настроект данной ветки. Можно подключать ветки настроек из других модулей, копировать их, сохранять все сразу или по отдельности, итд… Кроме того, обращение к элементу конфига идет не по программной ссылке, а по идентификатору или имени - можно легко обращаться к настройкам из плагинов. То есть конфиг получился очень гибким и независимым хранилищем настроек. Но поскольку конфиг используется в каждом кусочке программы, то пришлось переписать почти всю программу.
Основные модули программы:
Интерфейсные модули:
Вспомогательные модули:
Модули компонентов:
Есть и другие модули, часть из них устаревшие.
Ядро состоит из базовых классов, менеджеров и функций:
Кроме того, в ядре есть такие глобальные объекты, как:
Новые формы можно создавать обычным образом. Но нельзя оставлять их в RealChat.dpr. Во время работы программы создайте новую форму, Parent:=MainForm, при закрытии делайте Release().
Форму страницы создавайте в виде фрейма TFrame. Конструктор переопределите так, чтобы он принимал параметр Page: TChatPage, который описывает свойства страницы и позволяет установить обработчики событий страницы. Основные события - смена языка, стиля и статуса активности страницы. Страница не должна обращаться напрямую к другим страницам и компонентам - только к ядру. Для создания страницы используйте PagesManager.CreatePage.
Клиент должен быть наследником Core.TChatClient и реализовывать все его методы и свойства. Это методы обработки сообщений пользователя, работы с настройками, подключение-отключение, итд.. Клиент в свою очередь должен иметь свой конфиг (даже пустой), может создавать новые формы, регистрировать страницы. Доступ у клиента только к ядру и вспомогательным модулям. Если у клиента есть конфиг, то у конфига может быть визуальная форма с набором панелей. Панели содержат интерактивные контролы и привязаны к узлам конфига.