Ильдар Хабибуллин - Java 7 [Наиболее полное руководство]

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

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

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

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

Эта схема разработана еще в 80-х годах прошлого столетия в языке Smalltalk и получила название MVC (Model-View-Controller). Оказалось, что она применима во многих областях, далеких от метеорологии, всюду, где удобно отделить обработку от ввода и вывода информации.

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

В объектно-ориентированном программировании каждая из трех частей схемы MVC реализуется одним или несколькими классами. Модель обладает методами setXxx(), которые использует Контроллер для передачи информации в Модель. Одна Модель может получать информацию от нескольких Контроллеров. Модель предоставляет Виду методы getXxx () и isXxx () для получения информации.

В некоторых реализациях схемы MVC Вид и Контроллер не взаимодействуют. Контроллер, реагируя на события, обращается к методам setXxx() Модели, которые меняют хранящуюся в ней информацию. Модель, изменив информацию, сообщает об этом тем Видам , которые зарегистрировались у нее. Этот способ взаимодействия Модели и Вида получил название "подписка-рассылка" (subscribe-publish). Виды подписываются у Модели , и та рассылает им сообщения о всяком изменении состояния объекта методами fireXxx (), после чего Виды забирают измененную информацию, обращаясь к методам getXxx () и isXxx () Модели.

В других реализациях Контроллер руководит взаимодействием Модели и Вида.

По схеме MVC построены компоненты графической библиотеки Swing, которые мы рассмотрим в главе 11.

К середине 90-х годов XX века накопилось много схем, подобных MVC. В них сконцентрирован многолетний опыт тысяч программистов, выражены наилучшие решения типовых задач.

Вот, пожалуй, самая простая из этих схем. Надо написать класс, у которого можно создать только один экземпляр, но этим экземпляром должны пользоваться объекты других классов. Для решения поставленной задачи предложена схема Singleton, представленная в листинге 3.8.

final class Singleton{

private static Singleton s = new Singleton(0); private int k;

private Singleton(int i){ // Закрытый конструктор.

k = i;

}

public static Singleton getReference(){ // Открытый статический метод. return s;

public int getValue(){return k;} public void setValue(int i){k = i;}

} public class SingletonTest{

public static void main(String[] args){

Singleton ref = Singleton.getReference();

System.out.println(ref.getValue()); ref.setValue(ref.getValue() + 5);

System.out.println(ref.getValue());

}

}

Класс Singleton окончательный — его нельзя расширить. Его конструктор закрытый — никакой метод не может создать экземпляр этого класса. Единственный экземпляр s класса Singleton — статический, он создается внутри класса. Зато любой объект может получить ссылку на этот экземпляр методом getReference (), изменить состояние экземпляра s методом setValue ( ) или просмотреть его текущее состояние методом getValue ( ).

Это только схема — класс Singleton надо еще наполнить полезным содержимым, но идея выражена ясно и полностью.

Схемы проектирования были систематизированы и изложены в [7]. Четыре автора этой книги были прозваны "бандой четырех" (Gang of Four), а книга, коротко, "GoF". Схемы обработки информации получили название "design patterns". Русский термин еще не устоялся. Говорят о "шаблонах", "схемах разработки", "шаблонах проектирования".

В книге GoF описаны 23 шаблона, разбитые на три группы:

□ шаблоны создания объектов: Factory, Abstract Factory, Singleton, Builder, Prototype;

□ шаблоны структуры объектов: Adapter, Bridge, Composite, Decorator, Facade, Flyweight, Proxy;

□ шаблоны поведения объектов: Chain of Responsibility, Command, Interpreter, Iterator, Mediator, Memento, Observer, State, Strategy, Template, Visitor.

Описания даны в основном на языке C++. В книге [8] те же шаблоны представлены на языке Java. В ней описаны и дополнительные шаблоны. Той же теме посвящено электронное издание [9]. В книге [10] подробно обсуждаются вопросы разработки систем на основе design patterns.

К сожалению, нет возможности разобрать подробно design patterns в этой книге. Но каждый разработчик, программирующий на объектно-ориентированном языке, должен их знать. Описание многих разработок начинается словами: "Проект решен на основе шаблона...", и структура проекта сразу становится ясна для всякого, знакомого с design patterns.

По ходу книги мы будем указывать, на основе какого шаблона сделана та или иная разработка.

Заключение

Вот мы и закончили первую часть книги. Теперь вы знаете все основные конструкции языка Java, позволяющие спроектировать и реализовать проект любой сложности на основе ООП. Оставшиеся конструкции языка, не менее важные, но реже используемые, отложим до части IV. Части II и III книги посвятим изучению классов и методов, входящих в Core API. Это будет для вас хорошей тренировкой.

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