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

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

Реализация приложения калькулятора на уровне файла начинается с решения о том, к какому из трех видов проектов должен принадлежать калькулятор. Как упоминалось в главе 1, есть три возможности: приложение Windows, консольное приложение или библиотека классов. Если калькулятор будет приложением Windows, то он мог бы выглядеть так, как на рисунке.

Калькулятор, реализованный как приложение Windows, позволяет пользователям выполнять вычисления, щелкая на соответствующих кнопках. Чтобы сложить два числа, пользователь щелкнул бы на кнопке соответствующей цифры, а затем выбрал оператор, второе число и знак =. Знак = — это сигнал приложению калькулятора начать обработку введенных данных и отобразить результат в текстовом поле.

Второй вариант — реализация калькулятора как консольного приложения, где числа вводят в виде текста.

Калькулятор, как консольное приложение, не ожидает щелчков на кнопках; пользователь нажимает клавиши на клавиатуре и вводит соответствующие числа и операции. Как правило, знаком = служит клавиша <Enter>, запускающая вычисление и вывод результата на консоль. Как только одно вычисление заканчивается, цикл повторяется снова.

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

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

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

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

Отдельные части называются компонентами (component). (Некоторые называют их модулями (module), но лично я предпочитаю термин компоненты.) Компоненты с низкоуровневыми функциональными возможностями располагаются на рисунке ниже, а с высокоуровневыми — выше.

Каждый компонент выполняет специфическую задачу, высокоуровневые компоненты используют задачи, реализованные на более низком уровне. Идея заключается в том, чтобы каждый уровень нес ответственность за некоторые функциональные возможности, а другие уровни не дублировали их, повторно реализуя некоторые из них. Высокоуровневые функции зависят от низкоуровневых, а низкоуровневые от высокоуровневых — нет.

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

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