Здравствуйте, delphinchik, Вы писали:

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

Тогда надо предусмотреть виртуальмый метод в базовом модуле (от которого наследованы все модули) типа Refresh (или Update или как душе угодно). А в конкретных модулях уже реализуешь функциональность этого метода.

Здравствуйте, Dimonka, Вы писали:

D>Здравствуйте, delphinchik, Вы писали:

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

D>Тогда надо предусмотреть виртуальмый метод в базовом модуле (от которого наследованы все модули) типа Refresh (или Update или как душе угодно). А в конкретных модулях уже реализуешь функциональность этого метода.
В том то и дело чтобы в конкретном модуле реализовать функциональность метода Refresh, мне нужно из модуля обращаться к компонентам на форме и изменять их, что, учитывая логику архитектуры программы недопустимо.

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

Вообще это уже проектированием попахивает, а не проблемами языка.

Здравствуйте, Dimonka, Вы писали:

D>Тогда напиши, что такое у тебя "модули", что такое "главная форма", их задачи и какие проблемы возникают.

D>Вообще это уже проектированием попахивает, а не проблемами языка.
Ну да, проблема в проектировании, я и не говорил, что проблема в языке.
Главная форма — это модуль главной формы приложения (pas-файл).
Модули — это модули (pas-файлы) программы отвечающие за тематически сгруппированные операции, которые может выполнять юзер, работая с программой, в данном случае модуль является наследником от TAppModule, который в свою очередь наследник TDataModule.

Здравствуйте, delphinchik, Вы писали:

D>>Тогда напиши, что такое у тебя "модули", что такое "главная форма", их задачи и какие проблемы возникают.

D>>Вообще это уже проектированием попахивает, а не проблемами языка.
D>Ну да, проблема в проектировании, я и не говорил, что проблема в языке.
D>Главная форма — это модуль главной формы приложения (pas-файл).
D>Модули — это модули (pas-файлы) программы отвечающие за тематически сгруппированные операции, которые может выполнять юзер, работая с программой, в данном случае модуль является наследником от TAppModule, который в свою очередь наследник TDataModule.

Я бы не стал пример из статьи брать как основу структуры приложения. Это был не самый удачный и продуманный пример. Вот ещё один пример, на мой взгляд чуть более удачный:
http://www.devexpress.com/Support/BestPractices/VCL/SAP/
но на английском.

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

Здравствуйте, Dimonka, Вы писали:

D>Здравствуйте, delphinchik, Вы писали:

D>>>Тогда напиши, что такое у тебя "модули", что такое "главная форма", их задачи и какие проблемы возникают.

D>>>Вообще это уже проектированием попахивает, а не проблемами языка.
D>>Ну да, проблема в проектировании, я и не говорил, что проблема в языке.
D>>Главная форма — это модуль главной формы приложения (pas-файл).
D>>Модули — это модули (pas-файлы) программы отвечающие за тематически сгруппированные операции, которые может выполнять юзер, работая с программой, в данном случае модуль является наследником от TAppModule, который в свою очередь наследник TDataModule.

D>Я бы не стал пример из статьи брать как основу структуры приложения. Это был не самый удачный и продуманный пример. Вот ещё один пример, на мой взгляд чуть более удачный:
D>http://www.devexpress.com/Support/BestPractices/VCL/SAP/
D>но на английском.

D>Вообще есть смысл разделить модули на визуальные и невизуальные. Визуальные модули можно строить на основе фреймов (или окон, если приложение MDI). Таким образом сохранятся основные преимущества дельфи (типа визуального дизайнера).
D>Также необходимо создать класс описания модуля, который поможет программе узнать как называется модуль, загружен он или нет итд. И сделать менеджер описаний, в котором эти описания себя зарегистрируют. Такая структура избавит приложения от очень многих проблем.
Я только всеми руками за, вот и пытаюсь найти методы построения архитектуры приложения. Было бы неплохо, если бы вы дали мне ссылки на описание или примеры методов, о которых говорите. Или ссылки на книги. Был бы очень благодарен.

Здравствуйте, delphinchik, Вы писали:

D>Я только всеми руками за, вот и пытаюсь найти методы построения архитектуры приложения. Было бы неплохо, если бы вы дали мне ссылки на описание или примеры методов, о которых говорите. Или ссылки на книги. Был бы очень благодарен.

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

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

Здравствуйте, Dimonka, Вы писали:

D>Здравствуйте, delphinchik, Вы писали:

D>>Я только всеми руками за, вот и пытаюсь найти методы построения архитектуры приложения. Было бы неплохо, если бы вы дали мне ссылки на описание или примеры методов, о которых говорите. Или ссылки на книги. Был бы очень благодарен.

D>Зайди здесь в форум "Проектирование". Там очень много было тем, в которых обсуждались решения в области проектирования приложений.

D>Не зная специфики приложения, можно давать только какие-то общие советы. Например: почитай книги, указанные в списке используемой литературы из этой статьи.
Пишется программа для управления коллекциями (фильмов, музыки, софта и т.д.). В вышеупомянутое дерево загружается из базы весь список доступных коллекций. Минимальной единицей коллекции есть файл. Интерфейс программы строится примерно так, как написано в статье, которую Вы предлагали (на devexpress), я имею в виду визуально.

Здравствуйте, Беркович Вадим, Чудин Андрей, Вы писали:

БВЧ>Практически во всех проектах можно встретить те или иные паттерны проектирования. Но далеко не часто они

Уфф. Не могу сказать за Delphi, но на С# подход, описанный в статье только усложняет жизнь.
У меня есть проект MDI, до фига дочерних форм. Главная форма знает обо всех дочерних, потому что они объявлены ка поля формы. Кроме этого, на каждую форму по классу. У каждой формы статическое поле — соотв. класс. И зачем мне медиатор? Главная форма подписывается на события дочерних и посылает сигналы куда нужно. Каждый из классов ничего не знает ни о формах, ни о главной. Форма знает только свой класс. Главная форма знает только про свои дочерние и в ней зашита вся логика совмешения форм между собой. При создании очередной дочки — подписываемся на ее события и ждем
Зачем мне перечисления модулей? Зачем мне перечисления методов когда для них не зашита логика?