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

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

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

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

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

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

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

IMHO, анализ задачи - занятие субъективное, для того что бы узнать, что предложили бы разные теоретики, придется обращаться непосредственно к ним.

Можно попробовать всем вместе провести анализ этой задачи.

Как я понял, пользователю нужно иметь возможность просмотреть два документа:
* перечень элементов
* спецификация

Существуют два типа исходных файла:
* схема электрическая
* схема печатной платы

Для одного проекта можно указывать любое количество исходных файлов?

да, для пущей универсальности.

Я пока вижу только три явных объекта:
* проект (класс Project)
* схема (класс Circuit)
* плата (класс Board)

(а перечень и спецификация могут быть просто форматированным выводом данных классов Circuit и Board, соответственно)

И куда-то и как-то нужно засунуть дерево, может как часть MainWindow оставить. однако дерево непосредственно зависит от экземпляра Project.

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

Какие сущности есть в этой задачи.
Это конечно сам проект (Project).
Публичный конструктор этого класса может создавать только пустой проект.
Для загрузки/сохранения проекта можно предусмотреть специальную сущность или сущности, например ProjectLoader/ProjectSaver. Наследники этих классов можно начить загружать/сохранять проекты не только в SQLite-файлы, но и в XML-файлы или в простые текстовые файлы на удаленных серверах.

Проект по сути будет являтся коллекцией документов (Document). Можно сделать своих наследников для каждого документа (SpecDocument, ItemListDocument) или сделать специальные загрузчики, которые будут загружать разные типы данных в объект-документ.

Следующая сущность это источники данных (Source). Семейство классов наследников Source, умеющие загружать нужные данные из разных источников.

Имхо тут лучше один класс сделать - ProjectManager, который будет отвечать за загрузку проектов, сохранение в разных форматах и пр... И вообще он будет содержать коллекцию самих проектов. И только он должен знать что с каждым проектом делать. А MainWindow должен иметь к нему доступ и знать как этот проект отображать. Причем инстанс ProjectManager д.б. один - т.е. сделать его наследником от синглтона например.

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

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

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

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


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

Да, видимо я криво сказал. Сама по себе сущность "Проект" - нужна. Но над коллекцией этих сущностей и нужен мэнеджер.

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