Главная страница | Контакты | Случайная страница Автомобили Астрономия Биология География Дом и сад Другие языки Другое Информатика История Культура Литература Логика Математика Медицина Металлургия Механика Образование Охрана труда Педагогика Политика Право Психология Религия Риторика Социология Спорт Строительство Технология Туризм Физика Философия Финансы Химия Черчение Экология Экономика Электроника

Обязанность Операции

чтоформатировать void SetComposition(Composition*)

когда форматировать virtual void Compose ()

У пользователя найдется что сказать и по поводу логической структуры документа: предложений, аб­зацев, разделов, глав и т.д. Физическая структура в общем-то менее интересна. Большинству людей не важно, где в абзаце произошел разрыв строки, если в целом все отформатировано правильно. То же самое относится и к форматированию колонок и страниц. Таким образом, пользователи задают только высокоуровневые ограничения на физическую структуру, a Lexi выполняет их.

Проектирование редактора документов

Инкапсуляция алгоритма форматирования

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

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

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

Классы Compositor и Composition

Мы определим класс Compositor (композитор) для объектов, которые мо­гут инкапсулировать алгоритм форматирования. Интерфейс (см. табл. 2.2) по­зволяет объекту этого класса узнать, какие глифы надо форматировать и когда. Фор­матируемые композитором глифы являются потомками специального подкласса класса Glyph, который называется Composition (композиция). Композиция при создании получает объект некоторого подкласса Compositor (специализирован­ный для конкретного алгоритма разбиения на строки) и в нужные моменты пред­писывает композитору форматировать глифы, по мере того как пользователь изме­няет документ. На рис. 2.5 изображены отношения между классами Composition и Compositor.

Рис. 2.5. Отношения классов Composition и Compositor

Неформатированный объект Composition содержит только видимые глифы, составляющие основное содержание документа. В нем нет глифов, определяющих физическую структуру документа, например Row и Column. В таком состоянии композиция находится сразу после создания и инициализации глифами, которые должна отформатировать. Во время форматирования композиция вызывает опе­рацию Compose своего объекта Compositor. Композитор обходит всех потомков композиции и вставляет новые глифы Row и Column в соответствии со своим ал­горитмом разбиения на строки.¹ На рис. 2.6 показана получающаяся объектная структура. Глифы, созданные и вставленные в эту структуру композитором, за­крашены на рисунке серым цветом.

Каждый подкласс класса Compositor может реализовывать свой собствен­ный алгоритм форматирования. Например, класс SimpleCompositor мог бы осуществлять быстрый проход, не обращая внимания на такую экзотику, как «цвет» документа. Под «хорошим цветом» понимается равномерное распределе­ние текста и пустого пространства. Класс TeXCompositor мог бы реализовывать полный алгоритм TjX[Knu84], учитывающий наряду со многими другими веща­ми и цвет, но за счет увеличения времени форматирования.

Наличие классов Compositor и Composition обеспечивает четкое отде­ление кода, поддерживающего физическую структуру документа, от кода раз­личных алгоритмов форматирования. Мы можем добавить новые подклассы к классу Compositor, не трогая классов глифов, и наоборот. Фактически допус­тимо подменить алгоритм разбиения на строки во время выполнения, добавив одну-единственную операцию SetCompositor к базовому интерфейсу класса Composition.

¹ Композитор должен получить коды символов глифов Character, чтобы вычислить места разбиения на строки. В разделе 2.8 мы увидим, как можно получить информацию полиморфно, не добавляя спе­цифичной для символов операции к интерфейсу класса Glyph.

Рис. 2.6. Объектная структура, отражающая алгоритм разбиения на строки, выбираемый композитором