public static void main(String[] args){ double x = -23.567, y = 0.235; for (Operation op: Operation.values())

System.out.println(op.eval(x, y));

}

}

Объявление аннотаций

Аннотации, о которых уже шла речь в главе 1, объявляются интерфейсами специального вида, помеченными символом "at-sign", на жаргоне называемом "собачкой". Например, аннотация @Override, использованная нами в листинге 2.2, может быть объявлена так: public @interface Override{ }

Таково объявление самой простой аннотации — аннотации без элементов (marker annotation). У более сложной аннотации могут быть элементы, описываемые методами интерфейса-аннотации. У этих методов не может быть параметров, но можно задать значение по умолчанию, записываемое после слова default в кавычках и квадратных скобках. Например, следующий текст

public @interface MethodDescription{ int id();

String description() default "[Method]";

String date();

}

объявляет аннотацию с тремя элементами id, name и date. У элемента name есть значение по умолчанию, равное Method.

Объявление интерфейса-аннотации определяет новый тип — тип аннотации (annotation type).

Аннотация записывается в программе в тех местах, где можно записывать модификаторы. По соглашению аннотация записывается перед всеми модификаторами. Элементы аннотации записываются как пары "имя — значение" через запятую. В каждой паре имя отделяется от значения знаком равенства:

@MethodDescription( id = 123456,

description = "Calculation method", date = "04.01.2008"

)

public int someMethod(){

}

Если у аннотации только один элемент, то его лучше назвать value (), например:

public @interface Copyright{

String value();

}

потому что в этом случае можно записать значение этого элемента просто как строку в кавычках, а не как пару "имя — значение":

@ Copyright("2008 My Company") public class MyClass{

}

Разумеется, интерфейс-аннотация должен быть реализован классом Java, в котором надо записать действия, выполняемые аннотацией. Это можно сделать разными способами, но все они выходят за рамки нашей книги.

Теперь нам известны все средства языка Java, позволяющие проектировать решение поставленной задачи. Заканчивая разговор о проектировании, нельзя не упомянуть о постоянно пополняемой коллекции образцов проектирования (design patterns).

Design patterns

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

Нет ли подобных общих методов в программировании? Есть.

Допустим, вам поручили автоматизировать метеорологическую станцию. Информация от различных датчиков или, другими словами, контроллеров температуры, давления, влажности, скорости ветра поступает в цифровом виде в компьютер. Там она обрабатывается: вычисляются усредненные значения по регионам, на основе многодневных наблюдений делается прогноз на завтра, т. е. создается модель метеорологической картины местности. Затем прогноз выводится по разным каналам: на экран монитора, самописец, передается по сети. Он представляется в разных видах: колонках чисел, графиках, диаграммах.

Такая информационная система очень часто проектируется по схеме MVC.

Схема проектирования MVC

Естественно спроектировать в нашей автоматизированной системе три части.

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

□ Вторая часть, назовем ее Моделью (Model), принимает эту унифицированную информацию от Контроллера, ничего не зная о датчике и не интересуясь тем, от какого именно датчика она поступила, и преобразует ее по своим алгоритмам опять-таки к какому-то однообразному виду, например к последовательности чисел.

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

В чем удобство такой трехзвенной схемы? Она очень гибка. Замена одного датчика приведет к замене только одного модуля в Контроллере, ни Модель, ни Вид этого даже не заметят. Надо представить прогноз в каком-то новом виде, например для телевидения? Пожалуйста, достаточно написать один модуль и вставить его в Вид. Изменился алгоритм обработки данных? Меняем Модель.

Перейти на страницу:

Все книги серии В подлиннике

Похожие книги