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

Рекомендуем при чтении наших комментариев к программе, выполняющей функции калькулятора, занимать относительно скептическую позицию. Для реализма мы выполним несколько итераций разработки программы, создав несколько версий и продемонстрировав идеи, лежащие в основе каждой из них. Очевидно, что большинство из этих идей являются незавершенными и даже ошибочными, иначе нам пришлось бы слишком рано закончить эту главу. По мере продвижения вперед мы приведем примеры разных принципов и рассуждений, которых постоянно придерживаются проектировщики и программисты. Следует иметь в виду, что в этой главе мы еще не создадим достаточно удовлетворительный вариант программы, отложив эту задачу до следующей главы.

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

6.2.1. Стадии разработки программы

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

 

 • Анализ. Осознаем, что следует сделать, и описываем свое (текущее) понимание задачи. Такое описание называют набором требований или спецификацией. Мы не будем углубляться в детали разработки и записи этих требований. Этот вопрос выходит за рамки рассмотрения нашей книги, но он становится все более важным по мере увеличения масштаба задачи.

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

• Реализация. Записываем код, отлаживаем его и тестируем, для того чтобы убедиться, что программа делает то, что нужно.

6.2.2. Стратегия

 

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

• Какая задача должна быть решена? Для того чтобы ответить на этот вопрос, необходимо прежде всего попытаться уточнить, что вы пытаетесь сделать. Как правило, для этого формулируют описание задачи, т.е. пытаются понять, в чем заключается ее суть. На этом этапе вы должны встать на точку зрения пользователя (а не программиста); иначе говоря, должны задавать вопросы о том, что должна делать программа, а не о том, как она будет это делать. Спросите: “Что эта программа может сделать для меня?” и “Как бы я хотел взаимодействовать с этой программой?” Помните, большинство из нас являются опытными пользователями компьютеров.

 • Ясна ли постановка задачи? Для реальных задач на этот вопрос никогда нельзя ответить положительно. Даже студенческое упражнение бывает трудно сформулировать достаточно точно и конкретно. Поэтому попытайтесь уточнить постановку задачи. Было бы обидно решить неправильно поставленную задачу. Другая ловушка состоит в том, что вы можете поставить слишком много вопросов. Пытаясь понять, что вы хотите, легко увлечься и стать претенциозным. Почти всегда лучше задавать поменьше вопросов, чтобы программу было легче описать, понять, использовать и (возможно) реализовать. Убедившись, что этот подход работает, можно создать более изощренную “версию 2.0”, основанную на вашем опыте.

 • Выглядит ли задача решаемой при имеющихся времени, опыте и инструментах? Мало смысла начинать проект, который вы не сможете завершить. Если у вас мало времени на реализацию (включая тестирование) программы, в которой были бы учтены все требования, то лучше и не начинать ее писать. Потребуйте больше ресурсов (особенно времени) или (лучше всего) измените требования, чтобы упростить задачу.

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

 • Знаете ли вы, какие инструменты, библиотеки и тому подобные ресурсы вам могут понадобиться? Ответ почти всегда положительный. Даже на самых ранних этапах изучения языка программирования в вашем распоряжении есть небольшие фрагменты стандартной библиотеки С++. Позднее вы узнаете больше об этой библиотеке и способах ее эффективного использования. Вам понадобятся графика и библиотеки графического интерфейса пользователя, а также библиотеки для работы с матрицами и т.п. Получив небольшой опыт, вы сможете найти тысячи таких библиотек в веб. Помните: не стоит изобретать колесо, разрабатывая программное обеспечение для решения реальных задач. Однако при обучении программированию все обстоит в точности наоборот: ученик должен заново изобрести колесо, чтобы увидеть, как оно действует. Время, которое вы сэкономите, используя хорошую библиотеку, можно посвятить разработке других частей программы или отдыху. Как понять, что та или иная библиотека подходит для решения вашей задачи и имеет достаточно высокое качество? Это трудная проблема. Можно поспрашивать у коллег, в дискуссионных группах по интересам или попытаться поэкспериментировать с библиотекой на небольших примерах, прежде чем подключать ее к вашему проекту.

 • Проанализируйте части решения, которые описаны отдельно (и, возможно, используются в разных местах программы или даже в других программах). Для этого требуется опыт, поэтому в данной книге мы приводим много примеров. Мы уже использовали векторы (класс

), строки (класс ), а также потоки ввода и вывода ( и ). Эта глава содержит первые завершенные примеры проектирования, реализации и использования программы, содержащей типы, определенные пользователем ( и ). В главах 8 и 13–15 представлено много других примеров вместе с принципами их проектирования. Пока рассмотрим аналогию: если бы вы конструировали автомобиль, то начали бы с идентификации его составных частей, например колес, двигателя, сидений, дверных ручек и т.д. Современный автомобиль состоит из десятков тысяч таких компонентов. Реальная программа в этом отношении не отличается от автомобиля за исключением того, что состоит из фрагментов кода. Мы же не пытаемся создавать автомобили непосредственно из исходного сырья, т.е. из стали, пластика и дерева. Поэтому и программы не следует конструировать непосредственно из выражений, инструкций и типов, предусмотренных в языке. Проектирование и реализация составных компонентов является основной темой нашей книги и проектирования программного обеспечения вообще (пользовательские типы описаны в главе 9, иерархии классов — в главе 14, а обобщенные типы — в главе 20).

• Создавайте небольшие и ограниченные версии программы, решающие ключевые части вашей задачи. Начиная работу, мы редко хорошо понимаем задачу. Мы часто так думаем (разве мы не знаем, что такое калькулятор), но на самом деле это не так. Только сочетание размышлений над задачей (анализ) и экспериментирования (проектирование и реализация) дает нам солидное понимание того, что требуется для создания хорошей программы. Итак, пишите небольшие и ограниченные версии, чтобы достичь следующих целей.