crossplatform.ru

Здравствуйте, гость ( Вход | Регистрация )

 
Ответить в данную темуНачать новую тему
> ООП, структура программы
Litkevich Yuriy
  опции профиля:
сообщение 19.2.2011, 11:18
Сообщение #1


разработчик РЭА
*******

Группа: Сомодератор
Сообщений: 9637
Регистрация: 9.1.2008
Из: Тюмень
Пользователь №: 64

Спасибо сказали: 769 раз(а)




Репутация:   94  


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

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

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

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

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

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

Т.е. не просто соображения "как бы я сделал". А как это всё формально предлагается делать, разного рода теоретиками ООП.
Перейти в начало страницы
 
Быстрая цитата+Цитировать сообщение
kwisp
  опции профиля:
сообщение 19.2.2011, 11:56
Сообщение #2


астарожна ынтжинэр
*****

Группа: Участник
Сообщений: 1404
Регистрация: 26.11.2008
Из: ТаганрогРодинаЧехова
Пользователь №: 435

Спасибо сказали: 108 раз(а)




Репутация:   23  


Цитата(Litkevich Yuriy @ 19.2.2011, 11:18) *
Т.е. не просто соображения "как бы я сделал". А как это всё формально предлагается делать, разного рода теоретиками ООП.

та ну. программирование не математика тут по-моему нет четко ограниченного набора решений.
тут существуют некоторые рамки и приемы облегчения жизни с помощью полиморфизма инкапсуляции декомпозиции и прочего...
Перейти в начало страницы
 
Быстрая цитата+Цитировать сообщение
BRE
  опции профиля:
сообщение 19.2.2011, 12:39
Сообщение #3


Профессионал
*****

Группа: Участник
Сообщений: 1112
Регистрация: 6.3.2009
Из: Ростов-на-Дону
Пользователь №: 591

Спасибо сказали: 264 раз(а)




Репутация:   44  


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

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

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

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

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

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

Перейти в начало страницы
 
Быстрая цитата+Цитировать сообщение
Litkevich Yuriy
  опции профиля:
сообщение 19.2.2011, 14:43
Сообщение #4


разработчик РЭА
*******

Группа: Сомодератор
Сообщений: 9637
Регистрация: 9.1.2008
Из: Тюмень
Пользователь №: 64

Спасибо сказали: 769 раз(а)




Репутация:   94  


Цитата(BRE @ 19.2.2011, 14:39) *
Для одного проекта можно указывать любое количество исходных файлов?
да, для пущей универсальности.

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

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

И куда-то и как-то нужно засунуть дерево, может как часть MainWindow оставить. однако дерево непосредственно зависит от экземпляра Project.
Перейти в начало страницы
 
Быстрая цитата+Цитировать сообщение
BRE
  опции профиля:
сообщение 19.2.2011, 16:58
Сообщение #5


Профессионал
*****

Группа: Участник
Сообщений: 1112
Регистрация: 6.3.2009
Из: Ростов-на-Дону
Пользователь №: 591

Спасибо сказали: 264 раз(а)




Репутация:   44  


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

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

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

Следующая сущность это источники данных (Source). Семейство классов наследников Source, умеющие загружать нужные данные из разных источников.
Перейти в начало страницы
 
Быстрая цитата+Цитировать сообщение
Rocky
  опции профиля:
сообщение 19.2.2011, 21:24
Сообщение #6


Старейший участник
****

Группа: Участник
Сообщений: 530
Регистрация: 22.12.2008
Из: Санкт-Петербург
Пользователь №: 463

Спасибо сказали: 22 раз(а)




Репутация:   7  


Цитата(BRE @ 19.2.2011, 16:58) *
предусмотреть специальную сущность или сущности, например ProjectLoader/ProjectSaver.

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

Сообщение отредактировал Rocky - 19.2.2011, 21:24
Перейти в начало страницы
 
Быстрая цитата+Цитировать сообщение
Litkevich Yuriy
  опции профиля:
сообщение 19.2.2011, 22:27
Сообщение #7


разработчик РЭА
*******

Группа: Сомодератор
Сообщений: 9637
Регистрация: 9.1.2008
Из: Тюмень
Пользователь №: 64

Спасибо сказали: 769 раз(а)




Репутация:   94  


Цитата(BRE @ 19.2.2011, 18:58) *
Давай пока забудем про GUI, считаем что его нет.
без него эта программа не нужна (в столь навёрнутом виде). По-этому нужно и ГПИ тоже. И взаимодействие ГПИ и прочего друг с дружкой.

Цитата(Rocky @ 19.2.2011, 23:24) *
лучше один класс сделать - ProjectManager ...
не согласен. Менеджер проектов нужен для управления проектами. Это не сам проект. Коль произносим: "Проект", стало быть и сущность такая должна быть.
(К стати, в планах у меня было, чтобы проект мог содержать не только документы, но и подпроекты)

Цитата(Rocky @ 19.2.2011, 23:24) *
А MainWindow должен иметь к нему доступ ...
вот мне и интересно. Например, если для отображения дерева использовать MVC, то значит нужно будет ещё и модель написать, которая будет пользоватся данными из класса "Проект". А если я изменю потраха проекта, в будущем, я также должен буду и модель переписать. И получается, что такое разделение не на пользу а во вред. Либо встаивать модель в класс "Проект" (или сам проект делать моделью).
Перейти в начало страницы
 
Быстрая цитата+Цитировать сообщение
BRE
  опции профиля:
сообщение 19.2.2011, 22:41
Сообщение #8


Профессионал
*****

Группа: Участник
Сообщений: 1112
Регистрация: 6.3.2009
Из: Ростов-на-Дону
Пользователь №: 591

Спасибо сказали: 264 раз(а)




Репутация:   44  


Цитата(Litkevich Yuriy @ 19.2.2011, 22:27) *
без него эта программа не нужна (в столь навёрнутом виде). По-этому нужно и ГПИ тоже. И взаимодействие ГПИ и прочего друг с дружкой.

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

Цитата(Litkevich Yuriy @ 19.2.2011, 22:27) *
А если я изменю потраха проекта, в будущем, я также должен буду и модель переписать. И получается, что такое разделение не на пользу а во вред. Либо встаивать модель в класс "Проект" (или сам проект делать моделью).

Так для этого и нужно продумать и четко определить, какие ручки для внешнего воздействия должны торчать из класса Проект. Если сам интерфейс будет стабилен, то ты сможешь как угодно менять потраха.
Перейти в начало страницы
 
Быстрая цитата+Цитировать сообщение
Rocky
  опции профиля:
сообщение 19.2.2011, 23:13
Сообщение #9


Старейший участник
****

Группа: Участник
Сообщений: 530
Регистрация: 22.12.2008
Из: Санкт-Петербург
Пользователь №: 463

Спасибо сказали: 22 раз(а)




Репутация:   7  


Цитата(Litkevich Yuriy @ 19.2.2011, 22:41) *
не согласен. Менеджер проектов нужен для управления проектами

Да, видимо я криво сказал. Сама по себе сущность "Проект" - нужна. Но над коллекцией этих сущностей и нужен мэнеджер.
Перейти в начало страницы
 
Быстрая цитата+Цитировать сообщение
Iron Bug
  опции профиля:
сообщение 21.2.2011, 14:52
Сообщение #10


Профессионал
*****

Группа: Модератор
Сообщений: 1566
Регистрация: 6.2.2009
Из: Yekaterinburg
Пользователь №: 533

Спасибо сказали: 211 раз(а)




Репутация:   12  


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

Быстрый ответОтветить в данную темуНачать новую тему
Теги
Нет тегов для показа


1 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)
Пользователей: 0




RSS Текстовая версия Сейчас: 18.6.2018, 10:20