ООП, структура программы Опции

[Litkevich Yuriy]

Читал я некоторое время назад про вяского рода декомпозицию и т.п. Но как-то всё бестолку.

вот реальная задача:
Нужно сделать несложную программку, для получения текстовой конструкторской документации из фалов САПР.
Из файла эл.схемы - перечень элементов к ней, из файла печатной платы - спецификацию.

Программа задумана с концепцией "Проект", в проект входит список исходных файлов САПРа, см. снимок.

Слева панель - дерево проекта, в проект можно добавлять связанные с ним файлы. Щёлкнув по имени файла в дереве, в MDI-области появляется виджет представляющий информацию (например, в виде таблицы) о файле (перечень/спецификация).
В качестве файла проекта выбран файл БД SQLite.

Для получения из файла схемы её перечня элементов и из файла платы - спецификации, файл анализируется некой специальной функцией (её код в данный момент интереса не представляет).

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

Т.е. не просто соображения "как бы я сделал". А как это всё формально предлагается делать, разного рода теоретиками ООП.

[Litkevich Yuriy]

Давай пока забудем про GUI, считаем что его нет.

без него эта программа не нужна (в столь навёрнутом виде). По-этому нужно и ГПИ тоже. И взаимодействие ГПИ и прочего друг с дружкой.

лучше один класс сделать - ProjectManager ...

не согласен. Менеджер проектов нужен для управления проектами. Это не сам проект. Коль произносим: "Проект", стало быть и сущность такая должна быть.
(К стати, в планах у меня было, чтобы проект мог содержать не только документы, но и подпроекты)

А MainWindow должен иметь к нему доступ ...

вот мне и интересно. Например, если для отображения дерева использовать MVC, то значит нужно будет ещё и модель написать, которая будет пользоватся данными из класса "Проект". А если я изменю потраха проекта, в будущем, я также должен буду и модель переписать. И получается, что такое разделение не на пользу а во вред. Либо встаивать модель в класс "Проект" (или сам проект делать моделью).

[BRE]

без него эта программа не нужна (в столь навёрнутом виде). По-этому нужно и ГПИ тоже. И взаимодействие ГПИ и прочего друг с дружкой.

Это понятно, что без GUI она не нужна, но GUI должен взаимодействовать с ядром через определенное api.

А если я изменю потраха проекта, в будущем, я также должен буду и модель переписать. И получается, что такое разделение не на пользу а во вред. Либо встаивать модель в класс "Проект" (или сам проект делать моделью).

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