Главная » C# » Конкретизация процесса разработки программы Калькулятор в Visual C# (Sharp)

0

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

•   на уровне файлов организовываются создаваемые проекты и решения;

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

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

Если Калькулятор реализовывать как приложение Windows, то он  может  выглеть, как показано на рис. 2.3.

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

Калькулятор можно также реализовать как консольное приложение (рис. 2.4).

Рис. 2.4. Калькулятор, реализованный как консольное приложение

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

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

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

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

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

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

Рис. 2.5. Организация компонентов приложения калькулятора

Некоторые   программисты    применяют   вместо   термина    "компоненты"   термин

"модули",  но  я  предпочитаю  первый  термин.  Компоненты  организованы  таким

образом,   что   функциональность   низкого  уровня   находится   внизу   блок-схемы, а функциональность высокого уровня — вверху.

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

Приложения реализуются с применением либо нисходящей (top-down), либо воодящей   (bottom-up)  архитектуры.   Нисходящая   архитектура  означает  создание в первую очередь компонентов высших уровней, при этом компоненты низших уровней создаются по мере надобности. В противоположность, применение восхящей технологи означает, что сперва создаются компоненты низших уровней.

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

Источник: Гросс  К. С# 2008:  Пер. с англ. — СПб.:  БХВ-Петербург, 2009. — 576 е.:  ил. — (Самоучитель)

По теме:

  • Комментарии