Как вы строите приложение в C ++ модульно - PullRequest
Новая
       19

Как вы строите приложение в C ++ модульно

4 голосов
/ 05 ноября 2010

Это вопрос больше о том, как создать приложение на c ++, чем о c ++, по сути

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

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

Я относительно новичок в написании чего-либо функционального на C ++, до этого момента работавшего только над проектами классов, но я написал большое количество программ различных типов на PHP.

Если бы это был проект PHP, кажется, было бы просто протестировать любую функциональность:

  1. Я бы просто начал с интерактивной реализации
  2. записать его в небольшой файл
  3. написать код, который использовал функциональность
  4. встроить его в функцию
  5. импортировать эту функцию в мою большую часть кода.

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

Ответы [ 3 ]

2 голосов
/ 06 ноября 2010

Вообще говоря, ответом на ваш вопрос является использование классов и модульного тестирования. Выполните поиск в Интернете для Agile / Extreme Programming.

Идея такова:

  1. Делайте все гибкие истории (я позволю вам прочитать об этом самостоятельно)
  2. Вы разбиваете свой дизайн на классы
  3. Напишите модульные тесты, которые определяют «спецификацию» для вашего класса
  4. Написать пустые функции-заполнители.
  5. См. Модульные тесты не пройдены.
  6. Пишите код, пока модульные тесты не пройдут успешно.
  7. Вернитесь к шагу 3 и повторите для остальных классов.

Если вы пишете код таким образом, вы создаете многоразовый и надежный код.

Честно говоря, я лично не верю в TRUE TDD (разработку через тестирование) - я чувствую, что лучше писать ваши модульные тесты после того, как вы написали свой код (я чувствую надвигающееся пламя гибели, исходящее от криков пользователей) AGILE OR DIE! ").

РЕДАКТИРОВАТЬ: Если ваш вопрос больше соответствует действительности фактического ЗДАНИЯ нескольких классов, ну, это легко. Вообще говоря, каждый из ваших классов должен быть инкапсулирован в 2 файла (исходный код и заголовочный файл). Просто включите эти файлы (вместе с файлами из всех других классов, которые вы хотите использовать) в новый проект. #include "xxx.h" в соответствующих местах, где вам нужно использовать классы, написать свой код, который использует эти классы, и собрать. Вот и все.

1 голос
/ 05 ноября 2010

Я думаю, что это будет общая тактика для любого ОО проекта.

Сначала определите основные компоненты и убедитесь, что у вас есть очень полное понимание того, за что все отвечает.

ПишитеИнтерфейс для каждого компонента и проверьте (логически), чтобы убедиться, что он соответствует вашей проблеме.

Реализуйте каждый модуль.

Что касается тестирования, создайте модули тестера (заглушки): дляПример создания класса, который будет отправлять ввод в GUI, имитируя ввод, который будет отправлен фактическим компонентом.Поскольку у вас есть четкое представление об интерфейсе, то как будет получен этот результат, не имеет значения.

Повторите этот процесс для каждого компонента в вашей системе, а затем соедините их вместе.

Надеюсь, это поможет

0 голосов
/ 14 ноября 2010

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

  • Если у вас уже есть какой-то код, это может помочь нарисовать диаграмму того, что у вас есть. Здесь может помочь перьевая бумага или, что еще лучше, UML (кстати, Umbrello - хороший инструмент UML, который может импортировать существующие классы). Иногда я выполняю такого рода «проверку дизайна» после последнего коммита, и это помогает мне обнаружить некоторые тонкие проблемы, особенно на этапах проектирования, когда я ежедневно занимаюсь рефакторингом классов;
  • Если вы написали код для компонентов, я думаю, вы можете легко сформулировать некоторые требования для каждого из них, и из них вы можете создать несколько тестов (например, с помощью «UnitCPPLite»). В настоящее время у меня есть тест в главном файле с некоторым стандартным кодом, который запускает выполнение теста, прежде чем что-либо еще выполняется в приложении (хотя это все еще не оптимально);
  • Наконец, я бы добавил к рекомендации ComtriS идею «включить охрану» (если вы ее еще не используете), чтобы предотвратить многократное включение заголовочных файлов. Так что на практике я обычно получаю что-то вроде этого:

ЦСИ / CFoo.h: 

// class 'CFoo': header file
#ifndef CFOO_H
#define CFOO_H

#include <only_what_you_need_in_declaration_interface>

class CFoo {
    private:
        // class data
    public:
        // constructors, destructors, getters, setters, etc.
        void doWork();
    };
#endif /* CFOO_H */

ЦСИ / CFoo.cpp: 

// class 'CFoo': implementation file
#include "CFoo.h"
#include <what_you_need_in_addition_for_internal_workings_of_methods>

// code for other methods...

void CFoo::doWork() {
    // work
}

Надеюсь, это поможет.

...