2015-05-08 3 views
2

есть ли кто-нибудь, кто мог бы дать мне некоторые основные идеи о планировании концепции моего проекта на C++?концепция простого проекта C++ с 2 классами для ввода и результатами расчета

У меня есть графический интерфейс с двумя строками, кнопкой и полем результатов. (Позже я хочу, чтобы у меня было много редактирований для ввода и результата, но на данный момент я хочу, чтобы это было просто) Моя идея состояла в том, чтобы объединить все мои входные данные в новый класс (класс INPUT). Для результата я хочу объединить все результирующие данные в другом классе (класс RESULT). Для вычисления результатов я хочу создать метод (что-то вроде Сумма РЕЗУЛЬТАТ (INPUT in)). Я не хочу делать все это всего за 1 класс, мне нужны классы ввода и результата, потому что у меня будет много полей данных в окончательной версии

Будет ли это хорошей концепцией? Если да, где бы я написал метод вычисления (sum())? В классе INPUT класс RESULT или main.cpp?

+0

Возможно, вы захотите проверить концепцию [MVC (Model-View-Controller)] (http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller). –

ответ

0

Обычно, если у вас есть такой дизайн ввода/вывода (или результатов), вы хотите, чтобы какой-то третий объект: evaluator/operator вид вещей, где вы подаете вход и получаете результат в результате.

Так что, если вы хотите гибкость, я смотрю на это как три части, а не два:

  1. input инкапсулировать пользовательский ввод.
  2. evaluator/operator, который принимает вход и выводит result.
  3. result для инкапсуляции вычисленного результата от оператора.

Это даст вам три отдельных объекта: один для фокусировки на вычислении, а два других - для представления данных.

Это также общее с узловыми конструкций, например, так:

enter image description here

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

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

 Смежные вопросы

  • Нет связанных вопросов^_^