Интерфейс MultiDoc

public interface MultiDoc

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

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

      void processMultiDoc(MultiDoc theMultiDoc) {

          MultiDoc current = theMultiDoc;

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

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

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

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

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

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

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