Интерфейс MultiDoc

public interface MultiDoc

Интерфейс MultiDoc определяет интерфейс объекта, предоставляющего более одного фрагмента данных для печати для задания печати. «Doc» — это короткий, легко произносимый термин, означающий «фрагмент данных для печати», а «multidoc» — это группа из нескольких doc. Клиент передает заданию печати объект, реализующий интерфейс MultiDoc, и задание печати вызывает методы этого объекта для получения данных для печати.

Интерфейс MultiDoc предоставляет абстракцию, подобную «связанному списку» doc. Объект multidoc похож на узел связанного списка: он содержит текущий doc в списке и указатель на следующий узел (multidoc) в списке. Задание печати может вызвать метод getDoc() объекта multidoc, чтобы получить текущий doc. Когда задание печати будет готово перейти к следующему doc, оно может вызвать метод next() объекта multidoc, чтобы получить следующий multidoc, содержащий следующий doc. Поэтому код задания печати для доступа к multidoc может выглядеть так:

     void processMultiDoc(MultiDoc theMultiDoc) {

         MultiDoc current = theMultiDoc;

         while (current != null) {
             processDoc (current.getDoc());
             current = current.next();
         }
     }

Конечно, интерфейс MultiDoc можно реализовать любым способом, соответствующим контракту; реализация не обязана использовать связанный список.

Чтобы получить все данные для печати для задания печати с multidoc, прокси службы печати может использовать один из двух шаблонов:

1. Шаблон с чередованием: Получить doc из текущего multidoc. Получить объект, представляющий данные для печати, из текущего doc. Получить все данные для печати из объекта, представляющего данные для печати. Получить следующий multidoc из текущего multidoc и повторять, пока они не закончатся. (В приведенном выше примере кода используется шаблон с чередованием.)
2. Шаблон «все сразу»: Получить doc из текущего multidoc и сохранить его в списке. Получить следующий multidoc из текущего multidoc и повторять, пока они не закончатся. Затем выполнить итерацию по списку сохраненных doc. Получить объект, представляющий данные для печати, из текущего doc. Получить все данные для печати из объекта, представляющего данные для печати. Перейти к следующему doc в списке и повторять, пока они не закончатся.

Теперь рассмотрим клиент печати, который генерирует данные для печати на лету и не располагает ресурсами для хранения более одного фрагмента данных для печати за раз. Если бы прокси службы печати использовал шаблон «все сразу» для получения данных для печати, это создало бы проблему для такого клиента: клиенту пришлось бы хранить данные для печати всех doc до тех пор, пока прокси службы печати не вернется за ними, а клиент не может этого сделать. Для работы с таким клиентом прокси службы печати должен использовать шаблон с чередованием.

Чтобы решить эту проблему и упростить разработку клиентов, предоставляющих несколько doc для задания печати, каждый прокси службы печати, поддерживающий задания печати с multidoc, должен обращаться к объекту MultiDoc по шаблону с чередованием. То есть, получив объект MultiDoc, прокси службы печати будет вызывать getDoc() один или несколько раз, пока успешно не получит текущий объект Doc. Затем прокси службы печати получит данные для печати текущего doc и не будет переходить дальше, пока не получит все данные для печати или пока не произойдет неисправимая ошибка. Если прокси службы печати сможет продолжить работу, он будет вызывать next() один или несколько раз, пока успешно не получит либо следующий объект MultiDoc, либо указание на то, что больше объектов нет. Реализация интерфейса MultiDoc может исходить из того, что прокси службы печати будет следовать этому шаблону с чередованием; поведение реализации MultiDoc при любом другом порядке использования не определено.

Количество клиентских потоков, которые могут одновременно обращаться к одному и тому же multidoc, не ограничено. Поэтому все реализации интерфейса MultiDoc должны быть потокобезопасными при многопоточном доступе. Фактически клиентский поток может добавлять doc в конец (концептуального) списка, пока поток задания печати одновременно получает doc из начала списка; если объект multidoc правильно синхронизирует потоки, они не будут мешать друг другу.