Рисовалка графиков на Qt
Branch: master
Clone or download
Pull request Compare This branch is 16 commits ahead, 1 commit behind anastasia-trg:master.
Fetching latest commit…
Cannot retrieve the latest commit at this time.
Permalink
Type Name Latest commit message Commit time
Failed to load latest commit information.
docs
.gitignore
README.md
aredrawing.h
arefilling.h
axis.cpp
axis.h
curve.cpp
curve.h
curvespool.cpp
curvespool.h
filereader.cpp
filereader.h
input_file_generator.rb
main.cpp
mainwindow.cpp
mainwindow.h
qt_plots.pro
renderarea.cpp
renderarea.h

README.md

#qt_plots

Рисовалка графиков на Qt.

В коде присутствует попытка реализации парадигмы DCI. Т.к. используя DCI, необходимо думать прецендентами, то сначала представим все преценденты необходимые для успешного построения графиков кривых.

Use Cases

Представленная диаграмма говорит о том, что необходимо прочитать данные из файла, и отобразить их. Таким образом, Данные с которыми мы работаем представлены композиционным класом CurvesPool. Этому классу, в зависимости от Контекста, назначаются Роли: AreFilling (для заполнения) и AreDrawing (для отображения).

Classes

##Мысли по поводу DCI.

В тех немногих примерах, что мне приходилось видеть в интернетах, на тему реализации DCI, при добавлении объектам Ролей - те немногие авторы используют немного другой подход, для определения "инфецированных" классов объектов. Это им позволяет хранить данные, необходимые для работы Роли (или Ролей, если их несколько), но по моему, исходя из идеологии DCI, Роли не должны иметь данных, они должны только осуществлять действия. Поэтому, в моём случае, для реализации классов Ролей, я использую наследование от параметра шаблона (см. классы AreFilling и AreDrawing), правда для этого данные, с которыми работают Роли, необходимо делать protected (так проще). Естественно существует множество умных, хороших книжек, которые говорят о том, что нужно всё максимально инкапсулировать... Но в таком случае, для описания Ролей можно обойтись обычным делигированием, просто предоставляя Роли объект, который она должна изменять, а иначе совсем таки Java начинается...

Также, у тех немногих авторов, поскольку они выбрали немного другой путь, часто используется static_cast для доступа к необходимым методам Данных. Те самые книжки, о которых я уже упоминал, говорят и о том, что касты - это тоже плохо (хотя в динамически типизируемых языках - вполне в порядке вещей). Я считаю, что касты это не плохо, если их не очень много (мысли исключительно об удобстве кодинга). Поэтому, я применяю касты только в момент инъекции Ролей в Данные. А поскольку Роли не содержат своих данных - подобные действия вполне правомерны.

##TODO:

  • Возможно следует вынести в отдельный Контекст работу с классами Axis и Curve, реализовав для этого соответствующие Роли. Думаю что можно сделать по одной Роли на каждое действие, реализовав, при этом, спецификацию шаблона для конкретного класса Данных.
  • Надобно оси подписать, но мне что-то лень :)