Обобщенный Model-View-Controller

Errare humanum est perseverare diabolicum. Seneka

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

В работе были описаны основные используемые в MVC шаблоны проектирования: Mediator, Observer, Command – как решения типовых задач, которые возникают при проектировании графического приложения. И мне показалось излишним приводить примеры недальновидного кода. Во-первых, эта задача потребовала бы рассмотрения огромного количества вариантов, как например, это делается в книге [1]. А во-вторых, у меня была задача не просто написать очередную работу, описывающую достоинства классического MVC, а именно показать, как можно реализовать MVC с помощью обобщенного программирования языков Java и C#.

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

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

1 Я возьму с собой в дорогу…

Я возьму с собой в дорогу,
Ту не пройденную даль,
Эту речку - недотрогу,
Сердца радость и печаль.
Теплый взгляд любимых глаз,
Нежный плен прикосновений,
Уложу в тугой рюкзак…
Горы, степи и леса,
Песен ноты и куплеты,
И родные голоса,
Я возьму с собой в дорогу,
В путь к вершинам,
В небеса.
Алексей Митин

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

Все примеры собраны в проекте Eclipse SDK 3.3.0 (Europe) под названием MVC RSDN Refactoring. Пакеты проекта приводятся в соответствии с последовательностью повествования, надеюсь, это поможет вам не запутаться:

В подкаталоге проекта lib собраны следующие библиотеки:

Практически все демонстрационные примеры работы представляют собой модульные тесты.

В качестве платформы модульного тестирования использовался JUnit 4, который входит в комплект стандартной поставки Eclipse SDK (Eclipse Classic).

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

Приведенные в статье модульные тесты изначально компилировались на Java SE 6 (Mustang).

Примеры же, посвященные защитному программированию на основе контрактных спецификаций, проверялись аспектно-ориентированным компилятором AspectJ. Его поддержкой в Eclipse SDK я пользовался благодаря модулю расширения AJDT (AspectJ Development Tools) версии 1.5. Имейте в виду, что AJDT в стандартный комплект Eclipse SDK не входит.

В описании примеров я достаточно часто буду ссылаться на внутреннюю реализацию классов, поставляемых в комплекте JDK, не подтверждая сказанное листингом соответствующего исходного кода. Но вы можете самостоятельно убедиться в верности всего сказанного. Удобнее всего будет переходить от кода примеров к коду классов JDK, если подключить в Eclipse SDK исходный код JDK, который поставляется вместе с ним (файлом src.zip).

Для построения диаграмм классов использовалась программа ArgoUML 0.24.

Вот теперь, вооружившись до зубов компиляторами и библиотеками, пожалуй, и начнем.

2 Шаблон проектирования Observer

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

Шаблон проектирования Observer (Обозреватель), или Publisher/Subscriber (Издатель/Подписчик), позволяет построить такую зависимость 1:N (один ко многим), при которой изменение состояния одного объекта (издателя) приводит к автоматическому оповещению зависимых от него объектов (подписчиков). Для этого издатель ведет список подписчиков, по соответствующему запросу регистрирует или снимает регистрацию подписчиков, а также оповещает зарегистрированных подписчиков в случае соответствующего события. При этом между издателем и подписчиками формируется слабая связь: издатель обладает минимумом информации о своих подписчиках, достаточной для организации оповещения. Издатель диктует только контракт оповещения: любой объект, его реализующий (подписчик), может получать оповещения. Таким образом, достаточно однажды реализовать издатель, чтобы позже неоднократно подключать к нему любые объекты, заинтересованные в его состоянии.

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

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

2.1 Оповещение подписчиков и потоковая безопасность

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

Реализацию класса можно считать поточнобезопасной, если никакая последовательность операций над классом (вызовы методов, чтение и запись полей класса), как при однопоточном доступе, так и при доступе из нескольких потоков, не может привести к ситуации, когда класс перестанет удовлетворять собственной спецификации. Подробнее характеристики безопасности потока рассматриваются в публикации [3].

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

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

В первой части работы класс java.util.concurrent.CopyOnWriteArrayList был выбран в качестве списка подписчиков активной модели (класс Model), которая в рамках обобщенного MVC является издателем, в изменении состояния которого заинтересована модель списка (класс ListModel) и базовое представление (класс BaseView<M, P>). И теперь я покажу на примере, почему выбор пал именно на эту реализацию коллекции: сравним реализации издателя со списком подписчиков на основе класса Vector<E> и на основе класса CopyOnWriteArrayList<E>.

        package ru.rsdn.patterns.behavioral.observer;

/**
 * Абстрактный подписчик
 */publicinterface ISubscriber {
	/**
	 * Событие
	 */void eventHappen();
}

Абстрактный подписчик (интерфейс ISubscriber) описывает контракт оповещения: с одной стороны, любой объект, желающий получать уведомления от издателя, должен реализовать данный интерфейс, с другой стороны, издатель обязуется посредством вызова метода eventHappen оповестить зарегистрированного подписчика об изменении собственного состояния.

        package ru.rsdn.patterns.behavioral.observer;

/**
 * Подписчик
 */publicclass Subscriber implements ISubscriber {
	publicvoid eventHappen() {
		System.out.println("Пришло уведомление!");
	}
}

Подписчик (класс Subscriber) является тривиальным примером реализации данного контракта.

        package ru.rsdn.patterns.behavioral.observer;

import java.util.Collection;
import java.util.Collections;

/**
 * Абстрактный издатель
 * @param <T> тип коллекции подписчиков
 */publicabstractclass AbstractPublisher<T extends Collection<ISubscriber>> {
	protectedfinal T subscribers;

	/**
	 * Конструктор
	 * @param _subscribers коллекция подписчиков
	 */public AbstractPublisher(T _subscribers) {
		if (_subscribers == null)
			thrownew NullPointerException("Пустой параметр");
		subscribers = _subscribers;
	}

	/**
	 * Подписаться
	 * @param subscriber подписчик
	 */publicvoid subscribe(ISubscriber subscriber) {
		if (subscriber == null)
			thrownew NullPointerException("Пустой параметр");
		if (subscribers.contains(subscriber))
			thrownew IllegalArgumentException("Повторная подписка: " +
					subscriber);
		subscribers.add(subscriber);
	}

	/**
	 * Отписаться
	 * @param subscriber подписчик
	 */publicvoid unsubscribe(ISubscriber subscriber) {
		if (subscriber == null)
			thrownew NullPointerException("Пустой параметр");
		if (!subscribers.contains(subscriber))
			thrownew IllegalArgumentException("Неизвестный подписчик: " +
					subscriber);
		subscribers.remove(subscriber);
	}

	/**
	 * @return подписчики
	 */public Collection<ISubscriber> getSubscribers() {
		return Collections.unmodifiableCollection(subscribers);
	}
}

Абстрактный издатель (класс AbstractPublisher<T>) является заготовкой издателя. Параметр класса T определяет тип коллекции подписчиков – произвольная реализация интерфейса Collection<ISubscriber>. Сама коллекция (поле subscribers) инициализируется в конструкторе переданным параметром: таким образом, все наследники абстрактного класса AbstractPublisher<T> будут обязаны произвести явный вызов родительского конструктора первой инструкцией своего конструктора. Методы subscribe и unsubscribe описывают соответственно регистрацию и снятие регистрации подписчика. Метод getSubscribers, возвращающий неизменяемую коллекцию подписчиков, понадобиться нам при рассмотрении проблемы утечки памяти.

        package ru.rsdn.patterns.behavioral.observer.problems.thread;

import java.util.List;

import org.junit.Assert;

import ru.rsdn.patterns.behavioral.observer.ISubscriber;
import ru.rsdn.patterns.behavioral.observer.AbstractPublisher;
import ru.rsdn.patterns.behavioral.observer.Subscriber;

/**
 * Тестирование абстрактного издателя
 * @param <T> тип списка подписчиков
 */publicclass AbstractPublisherTest<T extends List<ISubscriber>> extends
		AbstractPublisher<T> {
	protectedfinal ISubscriber subscriber = new Subscriber();

	/**
	 * Конструктор
	 * @param _subscribers список подписчиков
	 */public AbstractPublisherTest(T _subscribers) {
		super(_subscribers);
	}

	/**
	 * Небезопасное оповещение подписчиков на основе перебора списка циклом
	 */publicvoid unsafeNotifyByCycle() {
		subscribe(subscriber);
		unsafeNotifyByCycle(subscribers);
	}

	protectedvoid unsafeNotifyByCycle(T _subscribers) {
		for (int i = 0; i < _subscribers.size(); i++) {
			if (i == _subscribers.size() - 1)
				invokeTrouble();
			_subscribers.get(i).eventHappen();
		}
	}

	/**
	 * Небезопасное оповещение подписчиков на основе перебора с использованием
	 * java.util.Iterator
	 */publicvoid unsafeNotifyByIterator() {
		subscribe(subscriber);
		for (final ISubscriber _subscriber : subscribers) {
			invokeTrouble();
			_subscriber.eventHappen();
		}
	}

	/**
	 * Имитировать проблему
	 */protectedvoid invokeTrouble() {
		new Thread(new Runnable() {
			publicvoid run() {
				unsubscribe(subscriber);
			}
		}).start();
		try {
			Thread.sleep(1000);
		} catch (final InterruptedException e) {
			Assert.fail();
		}
	}
}

Класс AbstractPublisherTest<T> представляет основу тестирования оповещения подписчиковиздателем. Класс AbstractPublisherTest<T> является абстрактным издателем, так как наследует класс AbstractPublisher<T> с уточнением: в качестве коллекции подписчиков будет использоваться список (реализация интерфейса List<ISubscriber>). Индексированная коллекция (список) необходима для тестирования перебора списка подписчиков циклом.

Все тесты оповещения первым делом регистрируют подписчик (поле subscriber), а затем с переменным успехом пытаются разослать уведомления зарегистрированным подписчикам, в нашем случае всего одному. Усложним им эту задачу: в цикле первой инструкцией (как было указано выше, это потенциально опасный участок кода: операция определения наличия элемента в списке выполнена, но элемент еще не был извлечен) имитируем вклинивание другого потока. Сторонний поток пытается снять регистрацию с подписчика в списке издателя, уведомление которому вот-вот должен отправить издатель. Имитация проблемы производится методом invokeTrouble: запускается новый поток, снимающий регистрацию с подписчика, основной же поток для верности на секунду усыпляется.

Первый тест (метод unsafeNotifyByCycle) осуществляет проверку оповещения подписчиков на основе перебора списка циклом. Метод перегружен методом с параметром для последующего использования в наследниках. Второй тест (метод unsafeNotifyByIterator) осуществляет аналогичную проверку, только перебор идет на основе использования java.util.Iterator.

Итак, проверим, как пройдут эти тесты на соответствие спецификации издатели со списком подписчиков на основе классов Vector<ISubscriber> и CopyOnWriteArrayList<ISubscriber>. И пусть победит сильнейший!

        package ru.rsdn.patterns.behavioral.observer.problems.thread;

import java.util.Collections;
import java.util.ConcurrentModificationException;
import java.util.Vector;

import org.junit.Test;

import ru.rsdn.patterns.behavioral.observer.ISubscriber;

/**
 * Тестирование издателя со списком подписчиков на основе java.util.Vector
 */publicclass VectorPublisherTest extends
		AbstractPublisherTest<Vector<ISubscriber>> {
	public VectorPublisherTest() {
		super(new Vector<ISubscriber>());
	}

	@Override
	@Test(expected = ArrayIndexOutOfBoundsException.class)
	publicvoid unsafeNotifyByCycle() {
		super.unsafeNotifyByCycle();
	}

	@Override
	@Test(expected = ConcurrentModificationException.class)
	publicvoid unsafeNotifyByIterator() {
		super.unsafeNotifyByIterator();
	}

	/**
	 * Безопасное оповещение подписчиков на основе перебора циклом
	 * блокированного списка
	 */
	@Test()
	publicvoid safeNotifyByCycleOnSynchronize() {
		synchronized (subscribers) {
			super.unsafeNotifyByCycle();
		}
	}

	/**
	 * Безопасное оповещение подписчиков на основе перебора копии списка
	 */
	@Test()
	publicvoid safeNotifyByCycleOnCopy() {
		subscribe(subscriber);
		final Vector<ISubscriber> subscribersCopy = new Vector<ISubscriber>();
		Collections.copy(subscribers, subscribersCopy);
		unsafeNotifyByCycle(subscribersCopy);
	}

}

По тесту (классу VectorPublisherTest) видно, что наш первый кандидат (издатель на основе класса Vector<ISubscriber>), к сожалению, провалился по всем статьям: каждый тест завершился соответствующим исключением. Это означает, что издатель по факту мог оповестить не всех подписчиков. Таким образом, издатель на основе класса Vector<ISubscriber> не выполнил требования спецификации, определенной нами выше, а значит, считать потокобезопасной подобную реализацию издателя мы не можем.

Первый тест (оповещение подписчиков циклическим перебором списка, метод unsafeNotifyByCycle) завершился исключением java.lang.ArrayIndexOutOfBoundsException. Объяснение здесь простое: основной поток определил наличие в списке одного элемента, поэтому зашел внутрь цикла, но затем вклинился сторонний поток, удалив единственный элемент из списка, и поэтому далее попытка основного потока извлечь из пустого уже списка элемент с индексом 0 завершилась соответствующим сбоем, который генерирует метод get класса Vector<E>.

Второй тест (оповещение на основе итеративного перебора списка, метод unsafeNotifyByIterator) завершился исключением java.util.ConcurrentModificationException. Исключение генерируется в реализации интерфейса Iterator<E>, которую предоставляет класс Vector<E>. Итератор определяется в классе java.util.AbstractList, который является родительским классом Vector<E>. При любой попытке модификации списка во время итеративного перебора внутренний класс ListIntr класса AbstractList<E> генерирует исключение ConcurrentModificationException.

Тесты safeNotifyByCycleOnSynchronize и safeNotifyByCycleOnCopy иллюстрируют частные решения данной проблемы: в первом случае список подписчиков просто блокируется на весь период оповещения, второй вариант осуществляет оповещение подписчиков циклическим проходом по временно созданной копии списка. По тесту видно, что данные варианты оповещения подписчиков делают издатель на основе класса Vector<ISubscriber> потокобезопасным. Тем не менее, оба варианта неблагоприятно отражаются на производительности: первый вариант блокирует все потоки, которым может потребоваться доступ к списку подписчиков, а второй вариант при каждом оповещении осуществляет достаточно затратную операцию по созданию временной коллекции и копированию в нее подписчиков.

Теперь посмотрим, как покажет себя в деле второй кандидат – издатель на основе класса CopyOnWriteArrayList<ISubscriber>.

        package ru.rsdn.patterns.behavioral.observer.problems.thread;

import java.util.concurrent.CopyOnWriteArrayList;

import org.junit.Test;

import ru.rsdn.patterns.behavioral.observer.ISubscriber;

/**
 * Тестирование издателя со списком подписчиков на основе
 * java.util.concurrent.CopyOnWriteArrayList
 */publicclass CopyOnWriteArrayListPublisherTest extends
		AbstractPublisherTest<CopyOnWriteArrayList<ISubscriber>> {
	public CopyOnWriteArrayListPublisherTest() {
		super(new CopyOnWriteArrayList<ISubscriber>());
	}

	@Override
	@Test(expected = ArrayIndexOutOfBoundsException.class)
	publicvoid unsafeNotifyByCycle() {
		super.unsafeNotifyByCycle();
	}

	@Override
	@Test()
	publicvoid unsafeNotifyByIterator() {
		super.unsafeNotifyByIterator();
	}
}

Как и ожидалось, первый тест (метод unsafeNotifyByCycle) издатель на основе класса CopyOnWriteArrayList<ISubscriber> тоже провалил. Причина аналогичная: операция извлечения элемента при циклическом проходе по списку не является атомарной.

Но зато оповещение подписчиков с помощью итеративного прохода по списку (второй тест в методе unsafeNotifyByIterator) было выполнено в соответствии со спецификацией издателя. Дело в том, что класс CopyOnWriteArrayList<E> гарантирует неизменность списка за счет перераспределения и копирования внутреннего массива данных при любой модификации. Таким образом, с одной стороны, любой поток может безопасно модифицировать список в любой момент времени, а с другой стороны, поток, перебирающий элементы списка с помощью предоставляемой реализации интерфейса Iterator<E>, будет считать, что список не изменяется, получая, тем не менее, после каждой модификации актуальную на данный момент времени версию списка. Стоит отметить также, что методы класса CopyOnWriteArrayList<E>, изменяющие внутренний массив данных, исключают гонки при перераспределении и копировании массива данных с помощью новой производительной блокировки, появившейся в JDK 1.5 в виде класса java.util.concurrent.locks.ReentrantLock. Детальное сравнение стандартной (synchronized) и блокировки с использованием класса ReentrantLock рассматривается в публикации [5].

Рисунок 1. Диаграмма классов тестирования потоковой безопасности издателя при оповещении подписчиков.

Итак, подведем итоги тестирования. С одной стороны, отдельные операции класса Vector<E> являются потокобезопасными, так как синхронизированы с помощью стандартного механизма блокировки synchronized. С другой стороны, последовательность действий, когда одно действие зависит от результата предыдущего, к примеру, проиллюстрированный выше перебор элементов, в котором действие извлечения элемента из списка зависит от действия по определению его наличия в списке, может привести к сбою. Подобные реализации называют условно потокобезопасными. Использование же класса CopyOnWriteArrayList<E> гарантирует потокобезопасность реализации издателя за счет встроенного перераспределения и копирования внутреннего массива данных при любой модификации списка, при этом риски конкурентной модификации списка исключаются с помощью более производительной блокировки (на основе класса ReentrantLock), нежели это делается в классе Vector<E>. Может показаться, что реализация неизменности списка в классе CopyOnWriteArrayList<E> пагубно скажется на производительности, ведь каждое изменение списка влечет за собой копирование внутреннего массива данных. Но развейте демонов сомнения, вспомните, что в большинстве случаев издатель имеет относительно небольшое количество подписчиков (внутренний массив данных класса CopyOnWriteArrayList<E> будет достаточно малым), а оповещение подписчиков (проход по списку элементов) вызывается намного чаще, нежели регистрация или снятие регистрации (модификация списка: соответственно добавление и удаление элемента списка). Таким образом, копирование внутреннего массива данных класса CopyOnWriteArrayList<E> не является столь затратной операцией, тем более что вызывается она в нашем случае достаточно редко. Подробнее о параллельных классах коллекций реализованных в JDK 1.5 читайте в публикации [6].

К чему я вел, вы уже, скорее всего, давно догадались: в качестве списка подписчиков в нашей потокобезопасной реализации издателя будет использоваться класс CopyOnWriteArrayList<E>.

2.2 Недействительные подписчики и утечка памяти

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

Например, издателем является объект Timer (программный таймер), в изменении состояния которого заинтересован объект Clock, отображающий на экранной форме часы с секундной стрелкой. При инициализации объект Clock регистрируется в качестве подписчика объекта Timer: при поступлении события от объекта Timer объект Clock перерисовывает текущее положение стрелок. Затем пользователь закрывает экранную форму с часами – все, жизненный цикл объекта Clock завершен. Предположим, что по причине безалаберности программиста (на самом деле могут быть и другие причины, мы рассмотрим их далее) объект Clock не снимает регистрацию по завершению работы, а значит, в списке подписчиков объекта Timer остается ссылка на неактуальный уже объект Clock. А тем временем объект Timer продолжает свое существование: когда пользователь снова пожелает посмотреть время, Timer будет помогать в перерисовке другому экземпляру класса Clock.

Во-первых, чем больше пользователь будет открывать часы, тем больше будет становиться список подписчиков в объекте Timer. И это несмотря на то, что после закрытия экранной формы с часами, ни один из подписчиков уже не является актуальным. В результате мы получаем необоснованный рост потребляемой памяти. В программных платформах, где управлением памятью занимается специальный код, называемый сборщиком мусора (Garbage Collector, GC), в общем случае, то есть, опуская все тонкости работы GC (в цели работы это не входит), память, выделенная под объект, может быть освобождена тогда и только тогда, когда на данный объект никто не ссылается. Это означает, что пока издатель хранит ссылку на подписчика, память, выделенная под объект подписчика, а также под все объекты, на которые в свою очередь ссылается сам подписчик, будет удерживаться в памяти до тех пор, пока не завершит работу сам издатель. Этот неприятный эффект называют удержанием памяти или утечкой памяти. К удивлению многих начинающих программистов, он имеет место, в том числе и в управляемых платформах.

Во-вторых, объект Timer и не подозревает, что является причиной того, что огромная толпа полумертвых объектов Clock не может спокойно уйти в мир иной. Издатель Timer продолжает рассылать уведомления всем подписчикам Clock, на которые хранит ссылки. Как себя поведет объект Clock, отобразивший некогда экранную форму с часами, но давно уже закрытую, при получении уведомления от объекта Timer? Это, скорее всего никому не ведомо, возможно, даже автору, столь безответственно его закодировавшему. В общем случае есть вероятность, что отправка уведомления такому недействительному подписчику приведет к сбою, то есть к исключению, которое будет выброшено ни в чем не повинному издателю.

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

2.2.1 Решение на стороне подписчиков

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

          package ru.rsdn.patterns.behavioral.observer.problems.leak;

import java.io.FileReader;
import java.io.IOException;
import java.io.Reader;

import org.junit.Assert;
import org.junit.Test;

import ru.rsdn.patterns.behavioral.observer.Subscriber;
import ru.rsdn.patterns.behavioral.observer.problems.init.CopyOnWriteArrayListPublisher;

/**
 * Тестирование подписчика, который может привести к утечке памяти, и
 * пересмотр его кода
 */publicclass MemoryLeakSubscriberTest extends Subscriber {
	privatefinal CopyOnWriteArrayListPublisher publisher = new CopyOnWriteArrayListPublisher();

	/**
	 * Неграмотная реализация печати содержимого файла
	 * @param file путь
	 * @throws IOException
	 */publicvoid unversedPrintFile(String file) throws IOException {
		publisher.subscribe(this);
		final Reader reader = new FileReader(file);
		int i;
		while ((i = reader.read()) != -1)
			System.out.print(i + ' ');
		publisher.unsubscribe(this);
	}

	/**
	 * Тестирование утечки памяти
	 */
	@Test
	publicvoid memoryLeakTest() {
		try {
			unversedPrintFile("Такого файла не существует");
		} catch (final IOException e) {
		}
		Assert.assertTrue(!publisher.getSubscribers().isEmpty());
	}

	/**
	 * Распечатать содержимое файла
	 * @param file путь
	 * @throws IOException
	 */publicvoid printFile(String file) throws IOException {
		publisher.subscribe(this);
		Reader reader = null;
		try {
			reader = new FileReader(file);
			int i;
			while ((i = reader.read()) != -1)
				System.out.print(i + ' ');
		} finally {
			publisher.unsubscribe(this);
			if (reader != null)
				reader.close();
		}
	}

	/**
	 * Тестирование отсутствия утечки памяти
	 */
	@Test
	publicvoid memoryNormTest() {
		try {
			printFile("И такого файла тоже не существует");
		} catch (final IOException e) {
		}
		Assert.assertTrue(publisher.getSubscribers().isEmpty());
	}
}

Класс MemoryLeakSubscriberTest содержит два теста. Каждый тест пытается вывести в консоль содержимое файла, при этом желает получать уведомления от издателя, которые также выводит в консоль (см. класс Subscriber). В первом тесте (метод memoryLeakTest) показан пример неграмотной реализации подписчика (метод unversedPrintFile), второй тест (метод memoryNormTest) показывает пересмотр кода подписчика (метод printFile). В обоих случаях из-за отсутствия файла, содержимое которого подписчик пытается распечатать, выбрасывается исключение java.io.FileNotFoundException. Первый тест показывает, что регистрация не снимается: список издателя по завершению не пустой – и это несмотря на то, что снятие регистрации было закодировано. Второй же тест напротив, корректно отрабатывает даже при исключении.

Кроме того, в прошлой работе я допустил непростительную оплошность: использовал для снятия регистрации нетривиальные финализаторы подписчиков – переопределенные в наследнике методы finalize суперкласса java.lang.Object. В Java-коде базовое представление (класс BaseView) снимало подписку с модели (класс Model) с помощью переопределенного метода finalize, а в C#-реализации представление (класс View) и представление списка (класс ListView) пользовались для снятия регистрации деструкторами. Дело в том, что сборщик мусора гарантирует финализацию объекта тогда и только тогда, когда на объект никто не ссылается. Таким образом, пока издатель хранит ссылку на подписчика, его финализатор вызван не будет. В итоге, в подписчиках фактически была закодирована утечка памяти.

Рассмотрим проблему еще раз на простом примере.

          package ru.rsdn.patterns.behavioral.observer.problems.leak;

import java.util.concurrent.CopyOnWriteArrayList;

import ru.rsdn.patterns.behavioral.observer.AbstractPublisher;
import ru.rsdn.patterns.behavioral.observer.ISubscriber;

/**
 * Подписчик, использующий финализатор для снятия регистрации
 */publicfinalclass NonTrivialFinalizeSubscriber implements ISubscriber {
	privatefinal AbstractPublisher<CopyOnWriteArrayList<ISubscriber>> publisher;

	/**
	 * Конструктор
	 * @param _publisher издатель
	 */public NonTrivialFinalizeSubscriber(
			AbstractPublisher<CopyOnWriteArrayList<ISubscriber>> _publisher) {
		if (_publisher == null)
			thrownew NullPointerException("Пустой параметр");
		publisher = _publisher;
		publisher.subscribe(this);
	}

	@Override
	protectedvoid finalize() throws Throwable {
		publisher.unsubscribe(this);
		super.finalize();
	}

	publicvoid eventHappen() {
	}
}

Класс NonTrivialFinalizeSubscriber является подписчиком (реализует интерфейс ISubscriber), который регистрируется в издателе при инициализации и снимает регистрацию при финализации (переопределенный метод finalize).

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

          package ru.rsdn.patterns.behavioral.observer.problems.leak;

import java.util.concurrent.CopyOnWriteArrayList;

import org.junit.Assert;
import org.junit.Test;

import ru.rsdn.patterns.behavioral.observer.AbstractPublisher;
import ru.rsdn.patterns.behavioral.observer.ISubscriber;

/**
 * Тестирование работы издателя с подписчиками, которые используют финализатор
 * для снятия регистрации, что приводит к утечке памяти
 */publicclass MemoryLeakNotTrivialFinalizeSubscriberTest extends
		AbstractPublisher<CopyOnWriteArrayList<ISubscriber>> {
	privatestaticfinalint N = 100;

	public MemoryLeakNotTrivialFinalizeSubscriberTest() {
		super(new CopyOnWriteArrayList<ISubscriber>());
	}

	@Test
	publicvoid memoryLeakTest() {
		for (int i = 0; i < N; i++) {
			new NonTrivialFinalizeSubscriber(this);
			System.gc();
			Assert.assertTrue(getSubscribers().size() == i + 1);
		}
		System.gc();
		Assert.assertTrue(getSubscribers().size() == N);
	}
}

Класс MemoryLeakNotTrivialFinalizeSubscriberTest представляет собой издателя (наследник класса AbstractPublisher<CopyOnWriteArrayList<ISubscriber>>). В тесте (метод memoryLeakTest) цикл на каждой итерации создает подписчика (экземпляр класса NonTrivialFinalizeSubscriber), который регистрируется в издателе (см. конструктор класса NonTrivialFinalizeSubscriber). Несмотря на то, что принудительно вызывается сборка мусора (статическим методом gc класса System), в конце каждой итерации цикла регистрируется увеличение количества зарегистрированных подписчиков на единицу. Каждая новая итерация цикла создает подписчик, при этом, нигде не сохраняя ссылку на него, то есть вроде бы это должно означать, что все подписчики созданные на предыдущих итерациях цикла являются потенциальными кандидатами на утилизацию сборщиком мусора, так как на них никто не ссылается. Но совсем позабыли, что ссылка остается в издателе! Приведенный тест показывает, что ни один из отработанных подписчиков не снял свою регистрацию с издателя: это регистрирует проверка по завершению цикла. Таким образом, ни один из финализаторов наших подписчиков вызван не был.

Рисунок 2. Диаграмма классов тестирования недействительных подписчиков и утечки памяти.

Итого, решение проблемы утечки памяти при использовании шаблона проектирования Observer на стороне подписчиков несет определенные трудности: проектирование каждого очередного подписчика требует высокого уровня ответственности. Так почему бы не попытаться решить проблему на стороне издателя? Ведь данный компонент проектируется один раз в отличие от множества его подписчиков.

2.2.2 Решение на стороне издателя

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

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

В JDK слабая ссылка представлена классом java.lang.ref.WeakReference. Объект, с которым необходимо установить слабую связь, передается в конструктор класса WeakReference<T> и его значение может быть получено методом get, который вернет пустую ссылку (null) в случае, если объект уже утилизирован. Подробнее про устранение проблемы утечки памяти посредством слабых ссылок можно прочитать в работе [10].

2.3 Безопасность инициализации подписчиков

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

Конструкторы имеют отличную от методов семантику. Предполагается, что объект будет полностью инициализирован, то есть перейдет в такое устойчивое состояние, в котором уже будет готов выполнять действия, диктуемые его спецификацией, только после завершения конструктора. Поэтому публиковать ссылку на не полностью сконструированный объект очень опасно. Когда конструктор делает видимым указатель на объект, говорят о так называемой потере указателя this. Подробнее про методы безопасного конструирования вы можете прочитать в публикации [11].

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

        package ru.rsdn.patterns.behavioral.observer.problems.init;

import java.util.Collection;

import ru.rsdn.patterns.behavioral.observer.ISubscriber;
import ru.rsdn.patterns.behavioral.observer.AbstractPublisher;

/**
 * Подписчик с риском безопасности инициализации из-за потери указателя this
 */publicabstractclass UnsafeInitSubscriber implements ISubscriber {
	/**
	 * Конструктор
	 * @param publisher издатель
	 */public UnsafeInitSubscriber(
			AbstractPublisher<Collection<ISubscriber>> publisher) {
		publisher.subscribe(this);
	}
}

Непосредственно в своем конструкторе класс UnsafeInitSubscriber регистрируется как подписчик переданного параметром publisher издателя, передавая при этом ссылку на себя (this) в его метод subscribe (см. класс AbstractPublisher<T>). И все бы ничего, но посмотрим, что может произойти при наследовании данного класса.

        package ru.rsdn.patterns.behavioral.observer.problems.init;

import java.util.Collection;
import java.util.LinkedHashSet;

import ru.rsdn.patterns.behavioral.observer.ISubscriber;
import ru.rsdn.patterns.behavioral.observer.AbstractPublisher;

/**
 * Подписчик, в котором проявляется наследованный риск безопасности
 * инициализации
 */publicclass InheritedUnsafeInitSubscriber extends UnsafeInitSubscriber {
	privatefinal Collection<Long> eventHistory;

	/**
	 * Конструктор
	 * @param publisher издатель
	 */public InheritedUnsafeInitSubscriber(
			AbstractPublisher<Collection<ISubscriber>> publisher) {
		super(publisher);
		eventHistory = new LinkedHashSet<Long>();
	}

	publicvoid eventHappen() {
		eventHistory.add(System.currentTimeMillis());
	}
}

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

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

        package ru.rsdn.patterns.behavioral.observer.problems.init;

import java.util.Collection;
import java.util.concurrent.CopyOnWriteArrayList;

import ru.rsdn.patterns.behavioral.observer.ISubscriber;
import ru.rsdn.patterns.behavioral.observer.AbstractPublisher;

/**
 * Издатель, который выявляет проблему небезопасного конструирования
 * подписчиков
 */publicclass InitNotifyPublisher extends
		AbstractPublisher<Collection<ISubscriber>> {
	public InitNotifyPublisher() {
		super(new CopyOnWriteArrayList<ISubscriber>());
	}

	@Override
	publicvoid subscribe(ISubscriber subscriber) {
		super.subscribe(subscriber);
		subscriber.eventHappen();
	}
}

Класс InitNotifyPublisher является издателем, который при регистрации подписчика осуществляет его немедленное оповещение.

Все, в принципе, сбой уже закодирован, осталось только запустить регистрирующий его тест.

        package ru.rsdn.patterns.behavioral.observer.problems.init;

import org.junit.Test;

/**
 * Тестирование подписчика, в котором проявляется наследованный риск
 * безопасности инициализации
 */publicclass InheritedUnsafeInitSubscriberTest {
	@Test(expected = NullPointerException.class)
	publicvoid test() {
		new InheritedUnsafeInitSubscriber(new InitNotifyPublisher());
	}
}

Тест InheritedUnsafeInitSubscriberTest создает издателя и передает ссылку на него в конструктор подписчика, в результате чего регистрирует исключение NullPointerException. Что же произошло? Дело в том, что издатель (класс InitNotifyPublisher) вызвал оповещение (метод eventHappen) еще не до конца инициализированного подписчика (класс InheritedUnsafeInitSubscriber). В частности подписчик еще не успел инициализировать коллекцию временных меток (см. конструктор класса InheritedUnsafeInitSubscriber). В результате при попытке сохранить временную метку события в методе eventHappen подписчик обратился к полю eventHistory, в котором на данный момент была пустая ссылка.

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

Рисунок 3. Диаграмма классов тестирования безопасности инициализации подписчиков.

Аналогичная ситуация происходит и при неявной потере указателя на объект (без использования this) в конструкторе. Это проявляется, к примеру, когда в конструкторе класса создается экземпляр анонимного класса подписчика, который далее регистрируется в издателе. Приведенный ниже пример аналогичен уже рассмотренному, потому привожу листинг без пояснений.

        package ru.rsdn.patterns.behavioral.observer.problems.init.implicit;

import java.util.Collection;

import ru.rsdn.patterns.behavioral.observer.ISubscriber;
import ru.rsdn.patterns.behavioral.observer.AbstractPublisher;

/**
 * Риск безопасности инициализации из-за неявной потери this при опубликовании
 * подписчика, являющегося экземпляром анонимного класса
 */publicabstractclass UnsafeImplicitInitSubscriber {
	/**
	 * Конструктор
	 * @param publisher издатель
	 */public UnsafeImplicitInitSubscriber(
			AbstractPublisher<Collection<ISubscriber>> publisher) {
		publisher.subscribe(new ISubscriber() {
			publicvoid eventHappen() {
				getEventHistory().add(System.currentTimeMillis());
			}
		});
	}

	/**
	 * @return история событий
	 */protectedabstract Collection<Long> getEventHistory();
}

        package ru.rsdn.patterns.behavioral.observer.problems.init.implicit;

import java.util.Collection;
import java.util.LinkedHashSet;

import ru.rsdn.patterns.behavioral.observer.ISubscriber;
import ru.rsdn.patterns.behavioral.observer.AbstractPublisher;

/**
 * Проявление наследованного риска безопасности инициализации из-за неявной
 * потери this при опубликовании подписчика, являющегося экземпляром
 * анонимного класса
 */publicclass InheritedUnsafeImplicitInitSubscriber extends
		UnsafeImplicitInitSubscriber {
	privatefinal Collection<Long> eventHistory;

	/**
	 * Конструктор
	 * @param publisher издатель
	 */public InheritedUnsafeImplicitInitSubscriber(
			AbstractPublisher<Collection<ISubscriber>> publisher) {
		super(publisher);
		eventHistory = new LinkedHashSet<Long>();
	}

	@Override
	protected Collection<Long> getEventHistory() {
		return eventHistory;
	}
}

        package ru.rsdn.patterns.behavioral.observer.problems.init.implicit;

import org.junit.Test;

import ru.rsdn.patterns.behavioral.observer.problems.init.InitNotifyPublisher;

/**
 * Тестирование проявления наследованного риска безопасности инициализации
 * из-за неявной потери this при опубликовании подписчика, являющегося
 * экземпляром анонимного класса
 */publicclass InheritedUnsafeImplicitInitSubscriberTest {
	@Test(expected = NullPointerException.class)
	publicvoid test() {
		new InheritedUnsafeImplicitInitSubscriber(
				new InitNotifyPublisher());
	}
}

2.4 Дефектные подписчики и отказоустойчивый издатель

Издатель рассылает уведомления подписчикам посредством вызова метода, описанного интерфейсом подписки. Что произойдет, если оповещение одного из подписчиков приведет к внутреннему сбою подписчика, например, если подписчик выбросит неконтролируемое исключение?

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

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

        package ru.rsdn.patterns.behavioral.observer.problems.fault;

import ru.rsdn.patterns.behavioral.observer.ISubscriber;

/**
 * Дефектный подписчик
 */publicclass FaultySubscriber implements ISubscriber {
	publicvoid eventHappen() {
		thrownew UnsupportedOperationException();
	}
}

Класс FaultySubscriber иллюстрирует дефектный подписчик: посланное издателем оповещение (метод eventHappen) приведет к генерации исключения java.lang.UnsupportedOperationException, являющегося неконтролируемым (наследником класса RuntimeException).

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

        package ru.rsdn.patterns.behavioral.observer.problems.fault;

import java.util.concurrent.CopyOnWriteArrayList;
import java.util.concurrent.atomic.AtomicBoolean;

import org.junit.Assert;
import org.junit.Test;

import ru.rsdn.patterns.behavioral.observer.AbstractPublisher;
import ru.rsdn.patterns.behavioral.observer.ISubscriber;

/**
 * Тестирование работы издателя и отказоустойчивого издателя с подписчиками,
 * среди которых есть один дефектный
 */publicclass FaultTolerantPublisherTest extends
		AbstractPublisher<CopyOnWriteArrayList<ISubscriber>> {
	public FaultTolerantPublisherTest() {
		super(new CopyOnWriteArrayList<ISubscriber>());
	}

	/**
	 * Тестирование отказа издателя из-за дефектного подписчика
	 */
	@Test(expected = RuntimeException.class)
	publicvoid crashNotifyTest() {
		subscribe(new FaultySubscriber());
		subscribe(new ISubscriber() {
			publicvoid eventHappen() {
				Assert.fail();
			}
		});
		notifySubscribers();
	}

	/**
	 * Оповещение подписчиков
	 */privatevoid notifySubscribers() {
		for (final ISubscriber subscriber : getSubscribers())
			subscriber.eventHappen();
	}

	/**
	 * Тестирование отказоустойчивого издателя
	 */
	@Test
	publicvoid normalNotifyTest() {
		subscribe(new FaultySubscriber());
		final AtomicBoolean notified = new AtomicBoolean();
		subscribe(new ISubscriber() {
			publicvoid eventHappen() {
				notified.set(true);
			}
		});
		faultTolerantNotifyAll();
		Assert.assertTrue(notified.get());
		Assert.assertTrue(getSubscribers().size() == 1);
	}

	/**
	 * Устойчивое к отказам оповещение подписчиков
	 */privatevoid faultTolerantNotifyAll() {
		for (final ISubscriber subscriber : getSubscribers())
			try {
				subscriber.eventHappen();
			} catch (final RuntimeException e) {
				System.err.println("Обнаружен дефектный подписчик: " +
						subscriber);
				unsubscribe(subscriber);
			}
	}
}

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

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

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

Рисунок 4. Диаграмма классов тестирования дефектных подписчиков и отказоустойчивого издателя.

Рассматриваемая далее реализация издателя является отказоустойчивой.

2.5 Издатель на слабых ссылках

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

        package ru.rsdn.patterns.behavioral.observer;

import java.lang.ref.WeakReference;
import java.util.Collection;
import java.util.HashSet;
import java.util.concurrent.CopyOnWriteArrayList;

/**
 * Издатель, использующий слабую связь с подписчиками
 * @param <S> тип подписчика
 */publicabstractclass Publisher<S> {
	privatefinal Collection<WeakReference<S>> subscribers = new CopyOnWriteArrayList<WeakReference<S>>();

	/**
	 * Подписаться
	 * @param subscriber подписчик
	 */publicvoid subscribe(S subscriber) {
		if (subscriber == null)
			thrownew NullPointerException("Пустой параметр");
		subscribers.add(new WeakReference<S>(subscriber));
	}

	/**
	 * Отписаться
	 * @param subscriber подписчик
	 */publicvoid unsubscribe(S subscriber) {
		if (subscriber == null)
			thrownew NullPointerException("Пустой параметр");
		for (final WeakReference<S> ref : subscribers) {
			final S _subscriber = ref.get();
			if (_subscriber == null || _subscriber == subscriber)
				subscribers.remove(ref);
		}
	}

	/**
	 * @return подписчики
	 */protected Collection<S> getSubscribers() {
		final Collection<S> result = new HashSet<S>();
		for (final WeakReference<S> ref : subscribers) {
			final S subscriber = ref.get();
			if (subscriber == null)
				subscribers.remove(ref);
			else
				result.add(subscriber);
		}
		return result;
	}
}

Абстрактный класс Publisher параметризован типом подписчика (параметр S). Таким образом, на основе класса Publisher<S> можно построить издатель произвольного контракта оповещения, подставив при наследовании вместо параметра S конкретный интерфейс абстрактного подписчика.

Список подписчиков (поле subscribers) представляет коллекцию на основе класса CopyOnWriteArrayList<WeakReference<S>>, таким образом, список хранит слабые ссылки на подписчиков – объекты типа WeakReference<S>. При регистрации подписчика (метод subscribe) на основе переданной в метод жесткой ссылки (параметр subscriber) создается слабая ссылка и добавляется в список. При снятии регистрации (метод unsubscribe) издателю необходимо по переданной жесткой ссылке (параметр subscriber) найти слабую ссылку и удалить ее из списка. Обратите внимание, что, перебирая список, издатель попутно удаляет слабые ссылки на уже недействительных подписчиков, то есть те слабые ссылки, метод get которых возвращает пустую ссылку.

Метод getSubscribers предназначен для реализации оповещения подписчиков в конкретных реализациях издателя (наследниках класса Publisher<S>), поэтому метод имеет видимость protected. В данном методе издатель также избавляется от уже недействительных подписчиков. Кроме того, обратите внимание, что класс Publisher<S> полностью скрывает свою внутреннюю реализацию на слабых ссылках: метод getSubscribers возвращает актуальные жесткие ссылки.

Предполагается, что добросовестные подписчики, работающие с издателем Publisher<S>, могут и будут снимать свою регистрацию по окончанию жизненного цикла методом unsubscribe. Но издатель не сильно расстроится, если один из его подписчиков будет закодирован более безответственно: как только подписчик выполнит предначертанное ему назначение в рамках приложения, его утилизирует сборщик мусора, а издатель перестанет оповещать его.

Рассмотрим пример издателя на слабых ссылках.

        package ru.rsdn.patterns.behavioral.observer.test;

import ru.rsdn.patterns.behavioral.observer.ISubscriber;
import ru.rsdn.patterns.behavioral.observer.Publisher;

/**
 * Пример издателя, использующего слабую связь с подписчиками
 */publicclass ConcretePublisher extends Publisher<ISubscriber> {
	privateboolean state;

	/**
	 * @return состояние
	 */publicboolean getState() {
		return state;
	}

	/**
	 * Установить состояние
	 * @param _state состояние
	 */publicvoid setState(boolean _state) {
		state = _state;
		notifySubscribers();
	}

	privatevoid notifySubscribers() {
		for (final ISubscriber subscriber : getSubscribers())
			try {
				subscriber.eventHappen();
			} catch (final RuntimeException e) {
				System.err.println("Обнаружен дефектный подписчик: " +
						subscriber);
				unsubscribe(subscriber);
			}
	}

	/**
	 * @return количество подписчиков
	 */publicint getSubscribersCount() {
		return getSubscribers().size();
	}
}

Класс ConcretePublisher является издателем с контрактом оповещения на основе интерфейса ISubscriber, использующим слабую связь с подписчиками за счет наследования класса Publisher<ISubscriber>. Состояние издателя хранит поле класса state, изменение которого приводит к оповещению всех подписчиков. Обратите внимание, что оповещение (метод notifySubscribers) является отказоустойчивым.

        package ru.rsdn.patterns.behavioral.observer.test;

import java.util.concurrent.atomic.AtomicBoolean;

import org.junit.Assert;
import org.junit.Test;

import ru.rsdn.patterns.behavioral.observer.ISubscriber;

/**
 * Тестирование примера издателя, использующего слабую связь с подписчиками
 */publicclass ConcretePublisherTest {
	/**
	 * Тестирование оповещения
	 */
	@Test
	publicvoid testNotify() {
		final ConcretePublisher publisher = new ConcretePublisher();
		finalboolean state = true;
		final AtomicBoolean notified = new AtomicBoolean();
		publisher.subscribe(new ISubscriber() {
			publicvoid eventHappen() {
				notified.set(true);
				Assert.assertTrue(publisher.getState() == state);
			}
		});
		publisher.setState(state);
		Assert.assertTrue(notified.get());
	}

	/**
	 * Тестирование слабой связи
	 */
	@Test
	publicvoid testWeakReference() {
		final ConcretePublisher publisher = new ConcretePublisher();
		ISubscriber subscriber = new ISubscriber() {
			publicvoid eventHappen() {
				Assert.fail();
			}
		};
		publisher.subscribe(subscriber);
		subscriber = null;
		System.gc();
		Assert.assertFalse(publisher.getSubscribersCount() > 0);
	}
}

Класс ConcretePublisherTest содержит два теста издателя на основе класса ConcretePublisher. Метод testNotify тестирует оповещение подписчика. Тест в методе testWeakReference иллюстрирует слабую связь издателя с подписчиком: после регистрации подписчика subscriber в издателе publisher, ссылка на подписчика «забывается» (в переменную subscriber записывается пустая ссылка) и принудительно вызывается сборка мусора, после чего фиксируется автоматическое снятие регистрации с подписчика в издателе.

Рисунок 5. Диаграмма классов тестирования издателя на слабых ссылках.

2.6 Множественный издатель

В реальном приложении встречаются объекты, которые инкапсулируют несколько логически не связанных между собой внутренних состояний. Использовать в данном случае класс Publisher<S> мы не сможем, так как он ограничивает издателя одним контрактом оповещения, который задает параметр S, а пользоваться же множественным наследованием в платформах Java и .NET нет ни возможности, ни желания. Потому рассмотрим реализацию обобщенного издателя, который позволит обслуживать произвольное количество контрактов подписки. Назовем такой издатель незамысловато – множественным. Разумеется, все решения, отраженные в приведенной выше реализации издателя, были перенесены и в реализацию множественного издателя.

        package ru.rsdn.patterns.behavioral.observer;

import java.lang.ref.WeakReference;
import java.util.Collection;
import java.util.HashSet;
import java.util.Map;
import java.util.concurrent.ConcurrentHashMap;
import java.util.concurrent.CopyOnWriteArrayList;

/**
 * Множественный издатель
 */publicabstractclass MultiPublisher {
	@SuppressWarnings("unchecked")
	privatefinal Map<Class, Collection<WeakReference<Object>>> subscribers = new ConcurrentHashMap<Class, Collection<WeakReference<Object>>>();

	/**
	 * Подписаться
	 * @param <S> тип подписчика
	 * @param _class интерфейс подписки
	 * @param subscriber подписчик
	 */protected <S> void subscribe(Class<? super S> _class, S subscriber) {
		if (_class == null)
			thrownew NullPointerException("Пустой параметр _class");
		if (subscriber == null)
			thrownew NullPointerException("Пустой параметр subscriber");
		if (!subscribers.containsKey(_class))
			subscribers.put(_class,
					new CopyOnWriteArrayList<WeakReference<Object>>());
		subscribers.get(_class).add(new WeakReference<Object>(subscriber));
	}

	/**
	 * Отписаться
	 * @param <S> тип подписчика
	 * @param _class интерфейс подписки
	 * @param subscriber подписчик
	 */protected <S> void unsubscribe(Class<? super S> _class, S subscriber) {
		if (_class == null)
			thrownew NullPointerException("Пустой параметр _class");
		if (subscriber == null)
			thrownew NullPointerException("Пустой параметр subscriber");
		if (!subscribers.containsKey(_class))
			thrownew IllegalArgumentException("Неизвестный тип подписки: " +
					_class);
		final Collection<WeakReference<Object>> _subscribers = subscribers
				.get(_class);
		for (final WeakReference<Object> ref : _subscribers) {
			final Object _subscriber = ref.get();
			if (_subscriber == null || _subscriber.equals(subscriber))
				_subscribers.remove(ref);
		}
	}

	/**
	 * @param <S> тип подписчиков
	 * @param _class интерфейс подписки
	 * @return подписчики
	 */
	@SuppressWarnings("unchecked")
	protected <S> Collection<S> getSubscribers(Class<? super S> _class) {
		final Collection<S> result = new HashSet<S>();
		if (subscribers.containsKey(_class)) {
			final Collection<WeakReference<Object>> _subscribers = subscribers
					.get(_class);
			for (final WeakReference<Object> ref : _subscribers) {
				final S subscriber = (S) ref.get();
				if (subscriber == null)
					_subscribers.remove(ref);
				else
					result.add(subscriber);
			}
		}
		return result;
	}
}

Множественный издатель (класс MultiPublisher) отличается от издателя (класса Publisher<S>) поддержкой различных контрактов подписки, поэтому вместо списка подписчиков используется карта. Карта построена на потокобезопасной реализации интерфейса java.util.Map – java.util.concurrent.ConcurrentHashMap. Выбор пал именно на данную реализацию карты по тем же причинам, что ранее привели к выбору класса CopyOnWriteArrayList<E> для организации списка подписчиков. Класс ConcurrentHashMap<K, V> используется для хранения соответствий между контрактом подписки и коллекцией подписчиков, удовлетворяющих данному контракту. Контракт подписки представляет собой тип интерфейса абстрактного подписчика: вместо первого параметра K класса ConcurrentHashMap подставляется метакласс java.lang.Class. Список подписчиков организуется аналогичным издателю образом, то есть на основе коллекции слабых ссылок на подписчиков: вместо второго параметра V класса ConcurrentHashMap подставляется коллекция слабых ссылок на произвольные объекты – Collection<WeakReference<Object>>.

Все методы множественного издателя параметризованы контрактом подписки (параметр S).

Регистрация осуществляется методом subscribe, при этом указывается тип подписчика (параметр _class) и жесткая ссылка на подписчика (параметр subscriber). При регистрации первого подписчика конкретного контракта подписки множественный издатель создает список слабых ссылок на основе класса CopyOnWriteArrayList<E> и сохраняет в карте (поле subscribers) соответствие типа контракта и данного списка. Здесь и далее, если множественный издатель находит зарегистрированные подписчики такого же типа, то создает слабую ссылку на подписчика на основе переданной в метод жесткой и добавляет ее в коллекцию подписчиков этого типа.

Снятие регистрации (метод unsubscribe) происходит аналогично издателю (см. метод unsubscribe класса Publisher<S>) за тем исключением, что поиск слабой ссылки на подписчика по переданной в метод жесткой (параметр subscriber) производится в коллекции, которая выбирается из карты subscribers по переданному в метод типу контракта подписки (параметр _class). Аналогичным образом видоизменено получение коллекции жестких ссылок на актуальных подписчиков (метод getSubscribers).

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

        package ru.rsdn.patterns.behavioral.observer.test;

import java.util.concurrent.atomic.AtomicBoolean;

import org.junit.Assert;
import org.junit.Test;

import ru.rsdn.patterns.behavioral.observer.ISubscriber;
import ru.rsdn.patterns.behavioral.observer.MultiPublisher;

/**
 * Тестирование примера множественного издателя, использующего слабую связь с
 * подписчиками
 */publicclass ConcreteMultiPublisherTest extends MultiPublisher {
	privateboolean state;

	privateboolean state1;

	/**
	 * @return состояние
	 */publicboolean getState() {
		return state;
	}

	/**
	 * Установить состояние
	 * @param _state состояние
	 */publicvoid setState(boolean _state) {
		state = _state;
		notifySubscribers();
	}

	privatevoid notifySubscribers() {
		for (final ISubscriber subscriber : getSubscribers(ISubscriber.class))
			try {
				subscriber.eventHappen();
			} catch (final RuntimeException e) {
				System.err.println("Обнаружен дефектный подписчик: " +
						subscriber);
				unsubscribe(ISubscriber.class, subscriber);
			}
	}

	/**
	 * @return дополнительное состояние
	 */publicboolean getState1() {
		return state1;
	}

	/**
	 * Установить дополнительное состояние
	 * @param _state дополнительное состояние
	 */publicvoid setState1(boolean _state) {
		state1 = _state;
		notifySubscribers1();
	}

	privatevoid notifySubscribers1() {
		for (final ISubscriber1 subscriber : getSubscribers(ISubscriber1.class))
			try {
				subscriber.eventHappen();
			} catch (final RuntimeException e) {
				System.err.println("Обнаружен дефектный подписчик: " +
						subscriber);
				unsubscribe(ISubscriber1.class, subscriber);
			}
	}

	/**
	 * @return количество подписчиков состояния
	 */publicint getSubscribersCount() {
		return getSubscribers(ISubscriber.class).size();
	}

	/**
	 * @return количество подписчиков дополнительного состояния
	 */publicint getSubscribers1Count() {
		return getSubscribers(ISubscriber1.class).size();
	}

	/**
	 * Тестирование оповещения
	 */
	@Test
	publicvoid testNotify() {
		finalboolean state = true;
		final AtomicBoolean notified = new AtomicBoolean();
		subscribe(ISubscriber.class, new ISubscriber() {
			publicvoid eventHappen() {
				notified.set(true);
				Assert.assertTrue(getState() == state);
			}
		});
		final AtomicBoolean notified1 = new AtomicBoolean();
		subscribe(ISubscriber1.class, new ISubscriber1() {
			publicvoid eventHappen() {
				notified1.set(true);
				Assert.assertTrue(getState1() == state);
			}
		});
		setState(state);
		Assert.assertTrue(notified.get());
		Assert.assertFalse(notified1.get());
		setState1(state);
		Assert.assertTrue(notified1.get());
	}

	/**
	 * Тестирование слабой связи
	 */
	@Test
	publicvoid testWeakReference() {
		ISubscriber subscriber = new ISubscriber() {
			publicvoid eventHappen() {
				Assert.fail();
			}
		};
		subscribe(ISubscriber.class, subscriber);
		subscriber = null;
		System.gc();
		setState(true);
		Assert.assertFalse(getSubscribersCount() > 0);
	}
}

Класс ConcreteMultiPublisherTest одновременно является примером множественного издателя (наследником класса MultiPublisher) и содержит тесты его работы. Множественный издатель инкапсулирует два состояния, которые хранятся в полях класса state и state1, и оповещает соответствующих подписчиков при любом изменении данных состояний. Контракт оповещения об изменении состояния (значения поля state) основан на интерфейсе ISubscriber. А объекты желающие узнавать об изменении дополнительного состояния (значения поля state1) множественного издателя должны реализовать интерфейс ISubscriber1, листинг которого не приводится, поскольку он аналогичен ISubscriber.

Набор тестов множественного издателя аналогичен набору тестов издателя, рассмотренных выше.

Рисунок 6. Диаграмма классов тестирования множественного издателя.

Немного отвлечемся от основной темы материала, чтобы рассмотреть одно из возможных применений множественного издателя.

2.6.1 Шаблон проектирования Model-View-Presenter

При реализации шаблона проектирования Model-View-Presenter (далее просто MVP) я обнаружил, что предъявитель является не только источником информации об изменении состояния модели, но, кроме того, знает, какие действия представление может осуществлять над данными модели в конкретный момент.

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

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

Таким образом, предъявитель в реализации MVP оповещает представления не только об изменении состояния модели, но и об изменении доступности действий, которые может инициировать представление. Казалось бы, изменение доступности действий обычно следует за изменением состояния модели. Но мне показалось, что данные события логически мало связаны. С одной стороны, источником информации об изменении состояния модели, в конечном счете, является сама модель, предъявитель же просто транслирует эту информацию в команду на обновление представления, отсылаемую в виде оповещения. А с другой стороны, предъявитель, интерпретируя команды представления на изменение данных модели, формирует некоторую историю, на основании которой и принимает решение о том, какие действия над данными модели могут быть доступны в данный момент. Таким образом, в первом случае источником события является изменение данных, а во втором – история изменений.

Демонстрационный пример использования обобщенного MVP в ASP.NET-приложении иллюстрирует использование данного решения на основе множественного издателя (см. ссылку выше).

3 Потоковая безопасность модели

Смотрите, блоков нет!
Брайан Гетц

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

Хорошая новость для платформы Java: начиная с Java SE 5 программистам наконец-то стали доступны так называемые неблокирующие алгоритмы, которые изучаются уже более 20 лет. Алгоритмы являются неблокирующими, потому что исключается сама потребность в блокировании: обеспечивается атомарность выполняемых действий. Неблокирующие алгоритмы также называют оптимистичными в том смысле, что они выполняются в предположении, что конфликтные ситуации в принципе исключены.

Современные процессоры имеют специальные инструкции для атомарного обновления разделяемых данных, которые чувствуют вмешательство стороннего потока при обновлении данных. И атомарные классы, которые вы можете найти в пакете JDK java.util.concurrent.atomic, используют данную возможность вычислителей в алгоритме сравнить и обновить (Compare And Set, CAS). Словесное описание алгоритма CAS можно сформулировать следующим образом: обновить переменную новым значением, но отказать, если другой поток изменил значение после моего последнего просмотра.

Атомарные классы имеют несомненные преимущества перед блокировками:

На основе атомарного класса ссылки (класс java.util.concurrent.atomic.AtomicReference) был пересмотрен код модели в части потокобезопасности по доступу к свойству модели.

      package ru.rsdn.patterns.mvc.model;

import java.util.concurrent.atomic.AtomicReference;
import java.util.concurrent.locks.ReentrantLock;

import ru.rsdn.patterns.behavioral.observer.Publisher;

/**
 * Модель
 * @param <P> свойство модели
 */publicclass Model<P> extends Publisher<IModelSubscriber<P>> {
	privatefinal AtomicReference<P> ref;

	privatefinal ReentrantLock lock = new ReentrantLock();

	/**
	 * Конструктор
	 * @param property свойство модели
	 */public Model(P property) {
		if (property == null)
			thrownew NullPointerException("Пустой параметр");
		ref = new AtomicReference<P>(property);
	}

	/**
	 * @return свойство модели
	 */public P getProperty() {
		return ref.get();
	}

	/**
	 * Установить свойство модели
	 * @param property свойство модели
	 */publicvoid setProperty(P property) {
		if (property == null)
			thrownew NullPointerException("Пустой параметр");
		if (ref.getAndSet(property) != property) {
			lock.lock();
			try {
				notifySubscribers();
			} finally {
				lock.unlock();
			}
		}
	}

	/**
	 * Оповестить всех подписчиков
	 */protectedvoid notifySubscribers() {
		for (final IModelSubscriber<P> subscriber : getSubscribers())
			notifySubscriber(subscriber);
	}

	privatevoid notifySubscriber(IModelSubscriber<P> subscriber) {
		try {
			subscriber.modelChanged(this);
		} catch (final RuntimeException e) {
			System.out.println("Обнаружен дефектный подписчик: " + subscriber);
			unsubscribe(subscriber);
		}
	}

	@Override
	publicvoid subscribe(IModelSubscriber<P> subscriber) {
		super.subscribe(subscriber);
		notifySubscriber(subscriber);
	}

	@Override
	public String toString() {
		return ref.get().toString();
	}
}

Класс Model теперь инкапсулирует атомарную ссылку на свойство модели (поле ref). В конструкторе класса Model на основе переданной ссылки на свойство модели (параметр property) создается атомарная ссылка – экземпляр класса AtomicReference.

В общем случае изменение свойства модели может инициировать не только контроллер, но и другие компоненты реального приложения, к примеру, компоненты уровня доступа к данным (Data Access Layer, DAL), так называемые объекты доступа к данным (Data Access Object, DAO), которые ответственны за загрузку данных и отправку изменений свойства модели в определенное хранилище данных. При этом изменение свойства модели приводит к автоматическому оповещению подписчиков (представлений и модели списка). Состязание за ссылку на свойство модели может привести к тому, что подписчики получат уведомление от модели об изменении свойства модели не на то значение, о появлении которого модель собственно и хотела их оповестить. Представлениям это, возможно, не столь критично, по-настоящему опасным является то, что DAO-объект может получить ссылку на свойство модели, которая уже не является актуальной.

Простейший CAS-алгоритм в методе setProperty исключает состязание изменения ссылки. Изменение ссылки потоком может привести к оповещению подписчиков только в том случае, если поток сделает это первым: успеет захватить старое значение ссылки и передать новое значение в метод getAndSet атомарного класса ссылки.

После изменения свойства модели идет оповещение подписчиков. При этом подписчики (к примеру, представления) вызовут у модели метод getProperty. Что если в этот момент другой поток уже снова изменяет ссылку на свойство модели новым значением? Да, представления при оповещении затребуют свойство модели и получат еще более новое значение ссылки, причем дважды: первый раз от первого потока, изменившего ссылку, затем повторно от следующего за ним. Это исключается блокировкой кода оповещения с помощью класса ReentrantLock.

4 Шаблон проектирования Command

Simply Brilliant: все сводится к простым истинам,
которыми зачастую пренебрегают в поиске ответов на сложные вопросы.
Фергус О’Коннел

Шаблон проектирования Command (Команда) (или Action (Действие), или Transaction (Транзакция)) используется в случае, если некоторый объект (инициатор), формирующий запрос на выполнение определенного действия, не обладает информацией о том, в чьей компетенции находится реализация данного действия. Решение заключается в том, что запрос инкапсулирует объект Command (Команда), который задает интерфейс выполнения действия. Инициатор формирует объект ConcreteCommand (Конкретная Команда) и отправляет его в запросе на выполнение. Клиент принимает запрос, устанавливает получателя запроса и преобразует объект ConcreteCommand в набор действий над получателем.

Приведенный в прошлой работе пример шаблона проектирования Command обладает определенными недостатками, которые будут сейчас исправлены. В частности было обнаружено следующее:

Таким образом, произошло достаточно сильное смещение обязанностей: от команды к контроллеру и от контроллера к представлению – в итоге команда получилась примитивной, а представление наоборот стало выполнять чужую работу. Кроме того, команды на основе перечислений являются далеко не лучшим решением в шаблоне проектирования Command даже в случае языка программирования Java, в котором перечисления могут содержать реализацию.

4.1 Команда

        package ru.rsdn.patterns.behavioral.command;

/**
 * Команда
 * @param <T> получатель
 */publicinterface ICommand<T> {
	/**
	 * Выполнить команду над получателем
	 * @param recipient получатель
	 * @return команда, отменяющая выполненную, или пустая ссылка, если
	 * команда не может быть выполнена
	 */
	ICommand<T> execute(T recipient);
}

Команда (интерфейс ICommand<T>), параметризованная получателем (параметр T), не только описывает выполнение действий над получателем (метод execute), но и требует от своих реализаций предоставления команды, которая описывает выполнение отменяющих действий (метод execute возвращает команду). При этом предполагается, что реализация метода execute вернет команду, которая сможет отменить все произведенные действия, только если данная команда действительно выполнится. В противном случае метод может вернуть пустую ссылку. Кроме того, обратите внимание, что команда получает информацию о том, над кем будут производиться действия (получателя), только в приказе на выполнение (параметр recipient метода execute). Клиент (контроллер) прикажет команде выполнить действия, когда установит получателя (модель) запроса, отправленного инициатором (представлением).

Рассмотрим три реализации команды: изменение, добавление и удаление модели – рассмотренные в прошлой работе команды отмены последнего изменения и повторения последнего отмененного действия оказались избыточными в пересмотренном варианте шаблона проектирования Command.

        package ru.rsdn.patterns.mvc.controller;

import ru.rsdn.patterns.behavioral.command.ICommand;
import ru.rsdn.patterns.mvc.model.Model;

/**
 * Команда на изменение модели
 * @param <P> свойство модели
 */publicclass EditCommand<P> implements ICommand<Model<P>> {
	privatefinal P property;

	/**
	 * Конструктор
	 * @param _property новое свойство модели
	 */public EditCommand(P _property) {
		if (_property == null)
			thrownew NullPointerException("Пустой параметр");
		property = _property;
	}

	public ICommand<Model<P>> execute(Model<P> model) {
		if (model == null)
			thrownew NullPointerException("Пустой параметр");
		final P oldProperty = model.getProperty();
		if (!property.equals(oldProperty)) {
			model.setProperty(property);
			returnnew EditCommand<P>(oldProperty);
		}
		returnnull;
	}
}

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

Команда отмены формируется и возвращается клиенту (контроллеру) после изменения модели. Если изменение модели не производится, то отменять собственно нечего и возвращается пустая ссылка. Команда отмены изменения также является командой на изменение модели, просто в качестве нового значения свойства модели (параметр конструктора property) она получает значение свойства модели до изменения (значение переменной oldProperty).

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

        package ru.rsdn.patterns.mvc.controller;

import java.util.Collection;
import java.util.Collections;

import ru.rsdn.patterns.behavioral.command.ICommand;
import ru.rsdn.patterns.mvc.model.ListModel;
import ru.rsdn.patterns.mvc.model.Model;

/**
 * Команда на добавление моделей
 * @param <P> свойство модели
 */publicclass AddCommand<P> implements ICommand<ListModel<P>> {
	privatefinal Collection<Model<P>> models;

	/**
	 * Конструктор
	 * @param _models добавляемые модели
	 */public AddCommand(Collection<Model<P>> _models) {
		if (_models == null)
			thrownew NullPointerException("Пустой параметр");
		models = _models;
	}

	/**
	 * Конструктор
	 * @param model добавляемая модель
	 */public AddCommand(Model<P> model) {
		if (model == null)
			thrownew NullPointerException("Пустой параметр");
		models = Collections.singleton(model);
	}

	public ICommand<ListModel<P>> execute(ListModel<P> model) {
		if (model == null)
			thrownew NullPointerException("Пустой параметр");
		for (final Model<P> _model : models)
			model.add(_model);
		returnnew RemoveCommand<P>(models);
	}
}

Команда на добавление моделей (класс AddCommand) получает в конструкторе (параметром _models) модели, которые необходимо добавить в модель списка (получатель запроса). Кроме того, инициатор (представление) может формировать запрос на добавление одной модели, пользуясь другим конструктором класса AddCommand: коллекция добавляемых моделей (поле models) инициализируется коллекцией из одного элемента. В приказе на выполнение команда принимает модель списка (получателя) и добавляет в нее последовательно все модели. В качестве отменяющей команда формирует команду на удаление моделей (экземпляр класса RemoveCommand), передавая ей список только что добавленных моделей. Листинг исходного кода класса RemoveCommand не приводится, потому что он отличается от процитированного только тем, что метод execute осуществляет удаление моделей и возвращает экземпляр класса AddCommand. В этом проявляется зеркальность команд на добавление и удаление: каждая является отменяющей действия другой.

4.2 Контроллер

        package ru.rsdn.patterns.mvc.controller;

import java.util.Stack;

import ru.rsdn.patterns.behavioral.command.ICommand;
import ru.rsdn.patterns.mvc.model.Model;

/**
 * Контроллер
 * @param <M> модель
 * @param
 * <P>
 * свойство модели
 */publicclass Controller<M extends Model<P>, P> {
	private M model;

	privatefinal Stack<ICommand<M>> undoCommands = new Stack<ICommand<M>>();

	privatefinal Stack<ICommand<M>> redoCommands = new Stack<ICommand<M>>();

	/**
	 * Установить модель
	 * @param _model модель
	 */publicvoid setModel(M _model) {
		model = _model;
		undoCommands.clear();
		redoCommands.clear();
	}

	/**
	 * Запрос на выполнение команды
	 * @param command команда
	 */publicvoid query(ICommand<M> command) {
		if (command == null)
			thrownew NullPointerException("Пустой параметр");
		execute(command, undoCommands);
	}

	privatevoid execute(ICommand<M> command, Stack<ICommand<M>> stack) {
		if (model != null) {
			final ICommand<M> undoCommand = command.execute(model);
			if (undoCommand != null)
				stack.push(undoCommand);
		}
	}

	/**
	 * Запрос на отмену последнего выполненного запроса
	 */publicvoid queryUndo() {
		if (!undoCommands.isEmpty()) {
			final ICommand<M> command = undoCommands.pop();
			execute(command, redoCommands);
		}
	}

	/**
	 * Запрос на повторное выполнение последнего отмененного запроса
	 */publicvoid queryRedo() {
		if (!redoCommands.isEmpty()) {
			final ICommand<M> command = redoCommands.pop();
			execute(command, undoCommands);
		}
	}
}

Функционал, который ранее выполняли контроллер и контроллер списка, являющиеся реализациями интерфейса абстрактного контроллера, удалось теперь реализовать всего в одном классе. В зависимости от подставленного вместо параметра M типа модели: модель (класс Model) или модель списка (класс ListModel) – класс Controller<M, P> будет представлять контроллер или контроллер списка. С одной стороны, это приведет к тому, что контроллер будет инкапсулировать модель соответствующего типа (полем model). С другой стороны, это ограничит тип команд, которые он (как клиент) сможет принимать в запросе от представления (инициатора). Это значит, что контроллеру (классу Controller<Model, P>) из рассмотренных нами выше реализаций команд можно будет отправить запрос только с командой на изменение модели, потому что ее получателем является модель: класс EditCommand реализует интерфейс ICommand<Model>. А контроллеру списка (класс Controller<ListModel, Collection<Mode>>) можно будет отправлять запросы только с командами на добавление или удаление моделей, потому что их получателем является модель списка: классы AddCommand и RemoveCommand реализуют интерфейс ICommand<ListModel>.

Модель, находящаяся в ведении контроллера, может меняться методом setModel, который сможет вызывать представление. Таким образом, инициатор (представление) имеет возможность, однажды назначив клиенту (контроллеру) подчиненного – получателя (модель), далее уже только слать запросы, то есть приказы с приложенной к ним инструкцией в виде команды. Представление может снова переназначить модельконтроллеру, когда решит переключиться с отображения одной модели на отображение другой. Кроме того, представление может и вовсе решить отключиться от отображения каких-либо данных, в этом случае у контроллера будет отобран подчиненный: представление передаст в метод setModel пустую ссылку.

Поддержку истории изменений, а соответственно возможность отмены последнего изменения и повтора последнего отмененного изменения, контроллер реализует на основе двух стеков: стек отмен (поле undoCommands) и стек повторений (поле redoCommands). Элементом истории, конечно же, является команда. В этом отношении более уместно другое название шаблона проектирования Command – Transaction.

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

Таким образом, контроллер может принимать запросы трех видов:

Рисунок 7. Диаграмма классов реализации шаблона проектирования Command в обобщенном MVC.

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

5 Защитное программирование

В конце концов, я по происхождению программист,
а оптимизм - это профессиональная болезнь данного ремесла.
Фредерик Брукс

Защитное программирование основано на важной предпосылке:
худшее, что может сделать модуль – это принять неправильные входные данные
и затем вернуть неверный, но правдоподобный результат.
Г. Майерс

Приведенный в прошлой работе код не был в достаточной мере наполнен защитными проверками. И сейчас не только будет исправлен этот недостаток, но и будут рассмотрены существующие решения в области защитного программирования на платформе Java, в частности наиболее интересное развитие данного направления – контрактные спецификации. В конце главы будет приведен пример использования данных решений в рамках обобщенного MVC.

Защитное программирование (Defensive Programming) является методикой написания программ, которая упрощает выявление и идентификацию появляющихся ошибок. Пожалуй, наиболее лаконичное определение принадлежит Майерсу [14], которое красуется эпиграфом данной главы.

Защитное программирование предполагает следование двум принципам: ожидание и локализация ошибки.

5.1 Ожидание ошибки

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

5.2 Локализация ошибки

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

5.3 Пример

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

        package ru.rsdn.defensive;

/**
 * Хранитель объекта, который не предполагает поступление ошибочных данных
 */publicclass OptimisticObjectHolder {
	privatefinal Object obj;

	/**
	 * Конструктор
	 * @param _obj объект
	 */public OptimisticObjectHolder(Object _obj) {
		obj = _obj;
	}

	@Override
	public String toString() {
		return obj.toString();
	}
}

В классе OptimisticObjectHolder закодирована потенциальная ошибка, причина которой – сделанное в переопределенном методе toString оптимистичное предположение относительно значения поля obj. Посмотрим, к чему может привести такая беспечность.

        package ru.rsdn.defensive;

import org.junit.Test;

/**
 * Тестирование хранителя объекта, который не предполагает поступление
 * ошибочных данных
 */publicclass OptimisticObjectHolderTest {
	/**
	 * Тестирование условий, на которые расчитывает хранитель объекта
	 */
	@Test
	publicvoid normTest() {
		final Object obj = "Некоторый объект";
		final OptimisticObjectHolder holder = new OptimisticObjectHolder(obj);
		System.out.println(holder.toString());
	}

	/**
	 * Тестирование условий, на которые хранитель объекта не расчитывал
	 */
	@Test(expected = NullPointerException.class)
	publicvoid crashTest() {
		final Object obj = null; // ошибкаfinal OptimisticObjectHolder holder = new OptimisticObjectHolder(obj); // ошибка// маскируется
		System.out.println(holder.toString()); // ошибка проявляется
	}
}

Первый тест (метод normTest) создает оптимальные условия, на которые и надеется класс OptimisticObjectHolder. Но автор класса OptimisticObjectHolder и не предполагал, что его детище попадет в ситуацию, показанную во втором тесте (метод crashTest): в конструктор класса передается пустая ссылка и при попытке вывести объект в консоль регистрируется исключение NullPointerException.

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

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

Чтобы найти источник ошибки нашего примера в общем случае придется пройти по пути ее следования в обратном направлении через следующие точки:

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

Пересмотрим код нашего примера в соответствии с принципами защитного программирования.

        package ru.rsdn.defensive;

/**
 * Хранитель объекта, который предполагает возможность поступления ошибочных
 * данных и локализует ошибку
 */publicclass ObjectHolder {
	privatefinal Object obj;

	/**
	 * Конструктор
	 * @param _obj объект
	 */public ObjectHolder(Object _obj) {
		if (_obj == null)
			thrownew NullPointerException("Пустой параметр");
		obj = _obj;
	}

	@Override
	public String toString() {
		return obj.toString();
	}
}

По спецификации хранитель объекта предназначен для работы со ссылкой на объект, другими словами хранитель не предназначен для работы с пустой ссылкой. Класс ObjectHandler предполагает, что может получить недопустимые его логикой данные. Поэтому первым же действием при поступлении входных данных в конструкторе класс ObjectHandler проверяет, являются ли они недопустимыми, то есть, является ли переданный в конструктор параметр _obj пустой ссылкой. В этом и заключается принцип ожидания ошибки. Принцип же локализации ошибки заключается в том, что если передана пустая ссылка, конструктор класса ObjectHandler выбрасывает исключение NullPointerException. При этом, во-первых, сторона, передающая некорректные данные, будет оповещена об этом, а во-вторых, таким образом, хранитель остановит распространение ошибки: генерируя исключение, конструктор тем самым отменяет создание объекта.

        package ru.rsdn.defensive;

import org.junit.Test;

/**
 * Тестирование хранителя объекта, который предполагает возможность
 * поступления ошибочных данных и локализует ошибку
 */publicclass ObjectHolderTest {
	@Test(expected = NullPointerException.class)
	publicvoid test() {
		final Object obj = null;
		final ObjectHolder holder = new ObjectHolder(obj);
		System.out.println(holder.toString());
	}
}

Тест ObjectHolderTest регистрирует ошибку на второй строке метода test. Таким образом, ошибка еще не успела замаскироваться: именно на попытке это сделать она и была выявлена, то есть в месте максимально близком к месту своего возникновения.

5.4 Утверждения

Работу по написанию защитных проверок могут облегчить утверждения (операторы assert). В этом случае не нужно задавать оператор условия и исключения: оператор assert подразумевает проверку, неудачное выполнение которой приводит к генерации исключения java.lang.AssertionError.

Таким образом, вы можете заменить достаточно избыточную запись:

        if (obj == null)
	thrownew NullPointerException("Пустая ссылка");

assert obj != null: "Пустая ссылка";

Кроме того, виртуальная машина может игнорировать утверждения (что по умолчанию и делается), то есть при необходимости все защитные проверки могут быть отключены разовым действием. Чтобы задействовать проверки, необходимо запускать виртуальную машину с параметром -ea (или -enableassertions). Данный ключ используется для разрешения утверждений во время выполнения приложения, без этого ключа операторы assert игнорируются, но все равно присутствуют в байт-коде, генерируемом компилятором.

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

5.5 Контрактные спецификации

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

На основе АОП развивается другое направление, предоставляющее развитые возможности по защитному программированию в ООП – контрактное программирование (Design By Contract, DBC). В идеале контрактное программирование должно гарантировать, что все компоненты системы выполняют именно то, что они и призваны выполнять, и пытается достичь этого явным указанием в интерфейсе компонента его функциональности и ожиданий клиентов. Ожидания клиентов реализуются на основе проверок входных данных компонента, которые называются предусловиями. Обязательство же компонента по реализации требуемой функциональности описывается постусловием, которое проверяет результат обработки входных данных, выполненной компонентом.

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

Хорошая новость для платформы Java: контракты можно строить на основе аннотаций, если использовать библиотеку OVal и аспектный компилятор AspectJ. При этом за счет того, что библиотека OVal предоставляет общую среду построения пред- и постусловий на Java SE 5, знание синтаксиса аспектного языка, в принципе, не требуется. Безопасное программирование на основе АОП и библиотеки OVal рассматривается в публикации [15].

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

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

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

        package ru.rsdn.defensive.sample;

import net.sf.oval.constraint.MatchPattern;
import net.sf.oval.constraint.NotNull;
import net.sf.oval.constraint.PossibleLength;
import net.sf.oval.guard.Guarded;

/**
 * Компания
 */
@Guarded
publicclass Company {
	privatestaticfinal String NO_NAME_MESSAGE = "Не указано название";

	privatestaticfinal String NO_TIN_MESSAGE = "Не указан ИНН";

	privatestaticfinal String ONLY_NUMBERS_TIN_MESSAGE = "ИНН должен содержать только цифры";

	privatestaticfinal String COUNT_NUMBERS_TIN_MESSAGE = "ИНН должен содержать 10 цифр";

	privatestaticfinal String NO_EMAIL_MESSAGE = "Не указана электронная почта";

	privatestaticfinal String INVALID_EMAIL_MESSAGE = "Некорректная электронная почта";

	@NotNull(message = NO_NAME_MESSAGE)
	private String name;

	@NotNull(message = NO_TIN_MESSAGE)
	@MatchPattern(pattern = "^\\d*$", message = ONLY_NUMBERS_TIN_MESSAGE)
	@PossibleLength(lengths = { 0, 10 }, message = COUNT_NUMBERS_TIN_MESSAGE)
	private String tin;

	@NotNull(message = NO_EMAIL_MESSAGE)
	@MatchPattern(pattern = "^(([a-z0-9]{1,}[\\.\\_\\-]?[a-z0-9]{1,})\\@([a-z0-9]{1,}[\\-]?[a-z0-9.]{1,}\\.)([a-z]{2,2}|org|net|com|gov|edu|int|info|biz|museum))?$", message = INVALID_EMAIL_MESSAGE)
	private String email;

	public Company() {
		name = "";
		tin = "";
		email = "";
	}

	/**
	 * Конструктор
	 * @param _name название
	 * @param _tin ИНН
	 * @param _email электронная почта
	 */public Company(String _name, String _tin, String _email) {
		name = _name;
		tin = _tin;
		email = _email;
	}

	/**
	 * @return название
	 */public String getName() {
		return name;
	}

	/**
	 * @return ИНН
	 */public String getTin() {
		return tin;
	}

	/**
	 * @return электронная почта
	 */public String getEmail() {
		return email;
	}

	@Override
	public String toString() {
		return name + ' ' + tin + ' ' + email;
	}

	@Override
	publicboolean equals(Object obj) {
		if (obj != null && obj instanceof Company) {
			final Company company = (Company) obj;
			return equals(name, company.getName()) &&
					equals(tin, company.getTin()) &&
					equals(email, company.getEmail());
		}
		returnsuper.equals(obj);
	}

	privatestaticboolean equals(Object obj0, Object obj1) {
		if (obj0 == null)
			return obj1 == null;
		return obj0.equals(obj1);
	}
}

Класс Company помечен аннотацией net.sf.oval.guard.Guarded, которая включает генерирование контрактных проверок класса.

Все поля класса помечены аннотацией net.sf.oval.constraint.NotNull. По данной аннотации будут сгенерированы предусловия – проверки любой попытки заменить значение соответствующего поля пустой ссылкой. Кроме того, будут созданы также и постусловия – проверки возврата значения поля класса в любом методе. При несоответствии контракту проверки генерируется исключение net.sf.oval.guard.ConstraintsViolatedException. Таким образом, однажды пометив поле класса аннотацией NotNull можно быть уверенным, что оно никогда не станет равным пустой ссылке.

Аннотация net.sf.oval.constraint.MatchPattern представляет контрактную спецификацию на основе регулярного выражения. К примеру, в случае ИНН регулярное выражение, задаваемое параметром pattern, описывает любую последовательность цифр, соответствующее регулярное выражение было построено и для электронной почты.

Обратите внимание, что в конструкторы контрактных спецификаций передаются строковые константы, которые являются сообщениями, уточняющими ошибки несоответствия контракту. При возникновении исключения несоответствия контрактной спецификации, данную уточняющую информацию можно получить у класса ConstraintsViolatedException методом getMessage, который наследуется от класса java.langThrowable. Эту информацию можно использовать для протоколирования и сигнализации пользователя.

Рисунок 8. Сквозная функциональность классов примера.

Рисунок 9. Сквозная функциональность класса Company.

OVal предоставляет достаточно большой набор реализованных контрактных спецификаций, которые можно найти в пакете net.sf.oval.constraint. Тем не менее, я не смог найти контрактную спецификацию, с помощью которой можно было бы задать несколько допустимых длин строки. Поэтому данную контрактную спецификацию PossibleLength реализовал самостоятельно. Посмотрим, насколько просто это делается с OVal.

        package net.sf.oval.constraint;

import java.lang.annotation.ElementType;
import java.lang.annotation.Retention;
import java.lang.annotation.RetentionPolicy;
import java.lang.annotation.Target;

import net.sf.oval.configuration.annotation.Constraint;

/**
 * Контрактная спецификация, описывающая допустимые длины строки
 */
@Retention(RetentionPolicy.RUNTIME)
@Target( { ElementType.FIELD, ElementType.PARAMETER, ElementType.METHOD })
@Constraint(checkWith = PossibleLengthCheck.class)
public @interface PossibleLength {
	/**
	 * @return допустимые значения длины
	 */int[] lengths() default {};

	/**
	 * @return сообщение об ошибке
	 */
	String message() default"";
}

Аннотация PossibleLength описывает необходимую нам контрактную спецификацию.

В разделе метаданных на основе аннотации java.lang.annotation.Retention задается область видимости нашей аннотации: метаинформация будет записана в байт-код и доступна во время исполнения через механизм рефлексии. С помощью аннотации java.lang.annotation.Target задается область применения аннотации PossibleLength. Нашу контрактную спецификацию можно применить к полям классов, параметрам методов (и конструкторов) и методу. Первые два случая служат для генерации предусловий, третий – постусловия. И последнее, что описывают метаданные – это класс, включающий логику проверки, соответствующей нашей контрактной спецификации. В конструкторе аннотации net.sf.oval.configuration.annotation.Constraint указан класс PossibleLengthCheck, который будет описан ниже.

PossibleLength включает два члена: метод lengths задает массив допустимых значений длины, message – сообщение об ошибке.

        package net.sf.oval.constraint;

import net.sf.oval.Validator;
import net.sf.oval.configuration.annotation.AbstractAnnotationCheck;
import net.sf.oval.context.OValContext;
import net.sf.oval.exception.OValException;

/**
 * Проверка контрактной спецификации, описывающей допустимые длины строки
 */publicclass PossibleLengthCheck extends
		AbstractAnnotationCheck<PossibleLength> {
	privatestaticfinallong serialVersionUID = 8624265267273032665L;

	privateint[] lengths;

	@Override
	publicvoid configure(final PossibleLength constraintAnnotation) {
		super.configure(constraintAnnotation);
		lengths = constraintAnnotation.lengths();
		message = constraintAnnotation.message();
	}

	publicboolean isSatisfied(final Object validatedObject,
			final Object value, final OValContext context,
			final Validator validator) throws OValException {
		if (value == null)
			returntrue;
		for (finalint length : lengths)
			if (length == value.toString().length())
				returntrue;
		returnfalse;
	}
}

Класс PossibleLengthCheck наследуется от абстрактного класса проверки на основе аннотации net.sf.oval.configuration.annotation.AbstractAnnotationCheck, которая уточняется описанной выше аннотацией PossibleLength. Переопределенный метод configure класса AbstractAnnotationCheck осуществляет настройку проверки: метод получает метаданные, которые использует для осуществления дальнейших проверок. Метод isSatisfied, определенный в наследованном интерфейсе net.sf.oval.Check, задает логику нашей проверки. Кроме того, обратите внимание, что описанная нами проверка, в принципе, может работать с любым объектным типом, потому что проверяет длину строки, которая получается вызовом метода toString у проверяемого объекта.

Теперь протестируем работу определенных нами контрактных спецификаций компании.

        package ru.rsdn.defensive.sample;

import java.util.Arrays;
import java.util.Collection;

import net.sf.oval.guard.ConstraintsViolatedException;

import org.junit.Test;
import org.junit.runner.RunWith;
import org.junit.runners.Parameterized;
import org.junit.runners.Parameterized.Parameters;

/**
 * Тестирование срабатывания контрактных спецификаций компании на некорректных
 * данных
 */
@RunWith(value = Parameterized.class)
publicclass CompanyCrashTest {
	privatefinal String name;

	privatefinal String tin;

	privatefinal String email;

	/**
	 * Конструктор
	 * @param _name название
	 * @param _tin ИНН
	 * @param _email электронная почта
	 */public CompanyCrashTest(String _name, String _tin, String _email) {
		name = _name;
		tin = _tin;
		email = _email;
	}

	@Parameters
	publicstatic Collection<?> data() {
		return Arrays.asList(new Object[][] { { null, "", "" },
				{ "", null, "" }, { "", "", null },
				{ "RSDN", "012345678", "submit@rsdn.ru" },
				{ "RSDN", "012abc6789", "submit@rsdn.ru" },
				{ "RSDN", "0123456789", "@rsdn.ru" } });
	}

	@Test(expected = ConstraintsViolatedException.class)
	publicvoid test() {
		try {
			new Company(name, tin, email);
		} catch (final ConstraintsViolatedException e) {
			System.out.println(e.getMessage());
			throw e;
		}
	}
}

Класс CompanyCrashTest оформлен параметризованным тестом, то есть представляет набор тестов значений, которые задаются методом data. Для каждого заданного кортежа значений: название, ИНН и электронная почта – будет вызван отдельный тест (метод test). Все заданные нами кортежи являются некорректными по одному из заданных значений: или задается пустая ссылка, или другое некорректное значение. Поэтому тест регистрирует генерирование исключения ConstraintsViolatedException при попытке создать экземпляра класса Company на основе данных значений. Кроме того, исключение в тесте перехватывается для того, чтобы вывести в консоль уточняющую информацию. Эту информацию исключению предоставляет контрактная спецификация, которая не может быть удовлетворена. После успешного прохождения теста в консоли можно наблюдать следующее:

        19.09.2007 21:01:55 net.sf.oval.guard.GuardAspect <init>
INFO: Instantiated
Не указано название
Не указан ИНН
Не указана электронная почта
ИНН должен содержать 10 цифр
ИНН долен содержать только цифры
Некорректная электронная почта

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

В качестве примера я создал представление компании (класс CompanyView наследующий класс View<Company>), которое позволяет изменять характеристики компании, но при этом контролирует ввод. Представление перехватывает исключение контрактной спецификации ConstraintsViolatedException компании при попытке создать экземпляр класса Company на основании введенных пользователем данных, протоколирует ошибку и сигнализирует пользователя о некорректном вводе.

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

6 Источники

Эта статья опубликована в журнале RSDN Magazine #4-2008. Информацию о журнале можно найти здесь

Обобщенный Model-View-Controller

Повышение качества графического интерфейса пользователя

Автор: Сергей Рогачев
ЗАО "Би-Эй-Си" | Группа компаний Астерос
Источник: RSDN Magazine #4-2008

Опубликовано: 26.04.2009
Исправлено: 10.12.2016
Версия текста: 2.0

1 Я возьму с собой в дорогу…

2 Шаблон проектирования Observer

2.1 Оповещение подписчиков и потоковая безопасность

2.2 Недействительные подписчики и утечка памяти

2.2.1 Решение на стороне подписчиков

2.2.2 Решение на стороне издателя

2.3 Безопасность инициализации подписчиков

2.4 Дефектные подписчики и отказоустойчивый издатель

2.5 Издатель на слабых ссылках

2.6 Множественный издатель

2.6.1 Шаблон проектирования Model-View-Presenter

3 Потоковая безопасность модели

4 Шаблон проектирования Command

4.1 Команда

4.2 Контроллер

5 Защитное программирование

5.1 Ожидание ошибки

5.2 Локализация ошибки

5.3 Пример

5.4 Утверждения

5.5 Контрактные спецификации

6 Источники

Обобщенный Model-View-Controller

Повышение качества графического интерфейса пользователя

Автор: Сергей РогачевЗАО "Би-Эй-Си" | Группа компаний АстеросИсточник: RSDN Magazine #4-2008

Опубликовано: 26.04.2009Исправлено: 10.12.2016Версия текста: 2.0

1 Я возьму с собой в дорогу…

2 Шаблон проектирования Observer

2.1 Оповещение подписчиков и потоковая безопасность

2.2 Недействительные подписчики и утечка памяти

2.2.1 Решение на стороне подписчиков

2.2.2 Решение на стороне издателя

2.3 Безопасность инициализации подписчиков

2.4 Дефектные подписчики и отказоустойчивый издатель

2.5 Издатель на слабых ссылках

2.6 Множественный издатель

2.6.1 Шаблон проектирования Model-View-Presenter

3 Потоковая безопасность модели

4 Шаблон проектирования Command

4.1 Команда

4.2 Контроллер

5 Защитное программирование

5.1 Ожидание ошибки

5.2 Локализация ошибки

5.3 Пример

5.4 Утверждения

5.5 Контрактные спецификации

6 Источники

Автор: Сергей Рогачев
ЗАО "Би-Эй-Си" | Группа компаний Астерос
Источник: RSDN Magazine #4-2008

Опубликовано: 26.04.2009
Исправлено: 10.12.2016
Версия текста: 2.0