Концепция и основные вопросы о разделении логики (C++) и GUI (Qt)

я закончил проект в C++. Это консольное приложение, созданное с помощью CodeBlocks. Хотя я считаю это не столь важным в рамках данного вопроса: приложение управляет данными о счетах и клиентах небольшой компании. Программа завершена и может быть очень легко расширена консольным пользовательским интерфейсом (прямо сейчас я запускаю ее как программист).

теперь я решил изучить программирование GUI с помощью Qt и QtCreator с QtDesigner!

не только потому, что это обычная практика, чтобы отделить логику от GUI при создании приложения GUI, я хочу, чтобы мой проект на практике в двух больших частях, а именно, конечно,логика и GUI. Вы уже знаете, что логическая часть завершена; у меня есть папка проекта под названием project содержит другую папку (проект CodeBlocks)project_logic, которая снова содержит несколько классов, таким образом, заголовочные файлы и файлы реализации (и main, которая, конечно, будет устаревшей, в конце концов). Он также содержит файлы из/в которые программа читает/записывает. Это написано на "чистом"C++ и использует нет средств, предоставляемых Qt и для меня важно, что это остается!

добавил Qt проект project_gui на project - папка и начал создавать GUI, реализуя только самые основные функциональные возможности, такие как изменение между диалогами, закрытие приложения и т. д. Пока он знает ничего о его будущем бэк-энде (project_logic).

в качестве третьего компонента мне нужен какой-нибудь управляя который связывает логику приложения с его GUI. Вот мой концептуальный вопрос:каков наилучший способ объединить их в одном приложении?

предложения

  1. С project_logic может работать в одиночку как консольное приложение, оно уже обеспечивает самые необходимые контролируя компоненты и функции. Это будет оставаться таким образом, потому что я хочу сохранить его функциональные. Тем более, что я совершенно новичок в программировании GUI и / или через две недели я могу создать другой GUI для той же логики. В результате классы логической части включаются в источник GUI, как и любой другой заголовок, и используются для создания программы с полной функциональностью. Проверка пользовательского ввода будет опираться на часть GUI. Этот логика программы в любом случае останется обновляемой.

  2. чтобы сделать GUI как можно более многоразовым; должен ли я реализовать третий компонент à la project_controlling что обеспечивает взаимодействие между GUI и логикой (проверка пользовательского ввода осуществляется путем управления) в том, что каждый из них остается как можно более независимым? GUI не включая заголовки логики, так сказать, но включая управляющие заголовки?

второй пункт может показаться немного немного странно, я признаю; короче говоря, мои цели:

  • держал project_logic стандартный C++ и независимая (С точки зрения исправления, добавления функциональности и т. д...) и
  • используя Qt для GUI при максимальном (в то же время разумном) разделении GUI и логики.

поезда мыслей

  1. должен ли я включить project_logic заголовки через #include "../project_logic/header1.h" etc? (Может возникнуть проблема с использованием классы, которые я опубликую в отдельном вопросе.)

  2. должен ли я включить их в качестве подпроекта?

  3. как бы я подключил части "в коде"?

  4. логические функции все еще находят файлы, которые я упоминал ранее (чтение/запись)?

пожалуйста, имейте в виду следующее: я новичок в программировании GUI! и я дал все возможное, чтобы объяснить мой мысли/проблемы... Тем не менее, я знаю C и C++ и пишу консольные приложения, которые я использую, например, для моделирования в университете, и могу справиться со стандартным материалом довольно хорошо, я считаю. Даже если потенциальный ответчик чувствует, что предлагает совсем другой подход, я был бы признателен за "решение" предложенной мной концепции. Причину этого я объяснил во введении. Излишне упоминать, что я, конечно, заинтересован в том, чтобы услышать разные предложения.

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

поскольку этот вопрос касается общего подхода, я, возможно, (вполне уверен... :- P) задайте более технические вопросы позже, которые я хотел бы отредактировать в этот вопрос (гиперссылки), как только они возникают. Однако основные рецепты в этом вопросе, если таковые имеются, приветствуются, конечно.

после некоторых комментариев и ответов мне хочется опубликовать небольшое редактирование, чтобы прояснить ситуацию:

текущее состояние логики

  • project_logic более или менее закончен и закодирован в CodeBlocks как проект CodeBlocks.
  • это мог бы работа в качестве консольного приложения с " console пользовательский интерфейс." (У него есть main.cpp который теперь используется только для отладки.)
  • его компоненты разделены на классы (заголовки и файлы реализации cpp) как можно больше.

текущее состояние GUI

  • project_gui настраивается как проект Qt-Widget-Application (с использованием QtCreator / Designer).
  • пока только GUI ничего больше (нет подключения к project_logic в любом путь.)

цели и ...

... the процесс, я хочу следовать, так как это мой первый большой проект:

  • project_logic и project_gui не покинет свои соответствующие каталоги; они оба находятся в каталоге под названием project. (Исключение: логика будет экспортироваться как dll (или что-то подобное) при необходимости, который затем предоставляется GUI.)
  • если были вещи, котор нужно изменить в project_logic Я хочу сделать это в CodeBlocks (и повторить возможный экспорт, как описано выше).
  • project_logic (или любой третий слой, как, например,project_controlling) должны быть сделаны одноразовые для project_gui наиболее простым образом... (см. поезда мыслей № 1): - P
15
c++ conceptual qt separation-of-concerns user-interface

2 ответов

  • если у вас есть отдельные проекты :

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

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

win32:CONFIG(release, debug|release): LIBS += -L$$PWD/Logic/release/ -lLogic
else:win32:CONFIG(debug, debug|release): LIBS += -L$$PWD/Logic/debug/ -lLogic

INCLUDEPATH += $$PWD/Logic
DEPENDPATH += $$PWD/Logic
  • в случае, если у вас есть все в одном проекте Qt:

в этом случае с помощью Subdirs хорошая идея отделить модули кода друг от друга. Таким образом, вы можете иметь независимые программные модули, которые могут быть повторно использованы и легко изменены. Это также делает проект намного чище и легче читать.

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

Qt Creator обеспечивает хорошую автоматизацию в симпатии частей друг к другу. Вы можете создать проект Subdirs и добавить в него свои подпроекты .pro файл:

TEMPLATE = subdirs

CONFIG += ordered

SUBDIRS += \
    Component1 \
    Component2 \
    Component3 \
    MainApp \

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

подпроекты Component1, Component2 и Component3 может быть библиотеки. Часть .pro файл для Component1:

TARGET = Component1
TEMPLATE = lib

DEFINES += COMPONENT1_LIBRARY

SOURCES += ...
HEADERS += ...

подпроекта MainApp может быть приложение. Часть .pro файл для MainApp :

TARGET = MainApp
TEMPLATE = app

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

win32:CONFIG(release, debug|release): LIBS += -L$$OUT_PWD/../Component1/release/ -lComponent1
else:win32:CONFIG(debug, debug|release): LIBS += -L$$OUT_PWD/../Component1/debug/ -lComponent1
else:unix: LIBS += -L$$OUT_PWD/../Component1/ -lComponent1

INCLUDEPATH += $$PWD/../Component1
DEPENDPATH += $$PWD/../Component1
3

Добро пожаловать в SO.

вы действительно связали два или три вопроса вместе здесь, но давайте попробуем:

в качестве третьего компонента мне нужен какой-то контроль, который связывает логика приложения с его GUI.

поскольку вы используете Qt, у вас есть встроенный ответ на этот вопрос:

Qt Project-Модель / Просмотр Программирования. Чтобы вы начали:

модель/представление архитектура

Model-View-Controller (MVC) - это шаблон проектирования, происходящий из Smalltalk, который часто используется при создании пользовательских интерфейсов. в проектировании Patterns, Gamma et al. пиши:

MVC состоит из трех видов объектов. Модель приложения объект, представление-его экранное представление и контроллер определяет реакцию пользовательского интерфейса на пользовательский ввод. Прежде чем в MVC, конструкции пользовательского интерфейса, как правило, объединяют эти объекты вместе. В MVC разъединяет их для повышения гибкости и повторного использования.

Если вид и объекты контроллера объединяются, в результате архитектура модель/представление. Это все еще разделяет способ, которым данные хранить от способа их представления пользователю, но обеспечивает простую структуру, основанную на тех же принципах. Это разделение делает возможно, для отображения тех же данных в различных представлениях и реализовать новые типы представлений без изменения базовые данные структуры. Для того чтобы позволить гибкой регуляции входного сигнала потребителя, мы вводим понятие делегата. Преимущество наличия делегата в этой framework заключается в том, что он позволяет отображать элементы данных и отредактировано для настройки.

модель MVC, явно поддерживаемая платформой QT (и возможная для реализации с другими фреймворками GUI, хотя и с большей работой), широко принята как надежная, гибкая группа шаблонов проектирования, которые обеспечивает управление и разделение различных слоев приложений, в том, как вы думаете - так что вы на правильном пути.

второй момент может показаться немного странным, я признаю; чтобы положить его короче, мои цели...

вопрос о том, как настроить проекты исходного кода, на самом деле не имеет ничего общего с вашей архитектурой приложения как таковой, хотя эти области обычно пересекаются так, что хорошая организация проекта облегчает более простая реализация вашей архитектуры, и наоборот. То, как вы организуете свой проект и его различные библиотеки и классы, может зависеть не только от проекта, над которым вы работаете сейчас, но и от планов будущих проектов. Например, как вы упомянули, Вы можете разработать определенные компоненты GUI, которые можно использовать для нескольких различных приложений. Если это так, вы можете поместить свои модули GUI в отдельную универсальную библиотеку многократного использования, которая может использоваться многими приложениями.

определенные правила, однако, применимы по всем направлениям и соблюдаются большинством опытных разработчиков - вот несколько больших, есть еще много:

  • один основной класс и его классы друзей на единицу (файл hpp/cpp).

  • будьте очень осторожны с тем, что вы включаете в заголовочные файлы и что вы оставляете своим cpp-файлам. Вы найдете рекомендации здесь по SO и в любой хорошей книге на C++ по этому вопросу, которая довольно важно, особенно в комплексе проекты. (От звука это, например, вопросы о том, как использовать #include и " соедините части "в коде - вам нужно лучше понять некоторые основы программирования на языке C++. Некоторые отличные книги там - вы можете найти списки здесь. C++ Primer (5-й Издание) это одно из лучших мест для начала.)

  • разбить классы и библиотеки с точки зрения их функциональность. Большинство IDES поддерживают виртуальный вложенные папки в проекте (не уверен в Code:: Blocks), чтобы помочь сохранить вещи организованными в таких манера. Это на самом деле попадает в фундаментальные вопросы дизайна, а не просто как изложить код в вашем проекте.

  • избежать жесткая связь!

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

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

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

в вашем случае кажется, что вы можете сделать, это упаковать свою "логику приложения" в одну библиотеку, ваши общие модули GUI во второй, а затем третий, тонкий исполняемый файл-возможно, просто содержащий main() и несколько строк, чтобы начать и закрыть их, когда закончите-это запускает приложение Qt и intializes классы в ваших библиотеках, которые взаимодействуют с использованием модели MVC и выполняют фактическую работу приложения. Три отдельные модули не нужны, хотя это будет более "общим" и многоразовым " и легче держать организованным таким образом.

вы действительно затронули широкий спектр вопросов с этим вопросом, и опять же, некоторые из них связаны с основами программирования на C++, а не просто "отделением логики приложения от GUI". Надеюсь, этот ответ поможет вам двигаться в правильном направлении.

важное замечание: GUI программирование является полным и не особенно легкая ветвь программирования. Есть специалисты по GUI и есть программисты, которые работают с GUI только минимально. (Я один из последних). Существует сайт SE под названием Опыт Пользователей который, хотя он не имеет дело с GUI Программирование per se, имеет дело с тем, как пользователи взаимодействуют с системами, что непосредственно связано с методами программирования GUI. Итак, когда вы говорите: "теперь я решил изучить программирование GUI", знайте, что вы берете на себя большую работу. Если вы действительно не заинтересованы в том, чтобы сделать программирование GUI своей специальностью, вы можете рассмотреть возможность использования мастеров и готовых решений GUI вместо того, чтобы делать все это вручную. QtCreator предоставляет некоторую такую поддержку, как и Code:: Blocks. Если вы намерены сделать этот серьезный бизнес, существуют также коммерческие рамки. Если вы не делаете это просто ради обучения, повторное изобретение колеса не рекомендуется для серьезной коммерческой работы по программированию.

3