CodeLAB
на главную карта сайта обратная связь

Популярные задачи:

#Случайный выбор элемента при неизвестном их количестве. (37716 hits)
#Переворот символов строки (или элементов одномерного массива). (113897 hits)
#Простая геометрическая и текстовая анимация. (401996 hits)
#Последовательный поиск и его оптимизации. (45574 hits)
#сортировка пузырьком. (154809 hits)
#Вычисление двойного интеграла с использованием MPI. (61332 hits)
#Часики на js. (97361 hits)
#Пирамидальная сортировка. (207790 hits)
#Утилиты. (116029 hits)
#Поиск дубликатов внутри файла. (32318 hits)
#Полезные утилиты, небольшие api и библиотеки и проч.. (70851 hits)
#Относительный путь к файлу. (40863 hits)
#Простая быстрая сортировка. (114599 hits)
#Наибольший общий делитель. (195214 hits)
#Поверхностное клонирование. (28541 hits)
#Случайный выбор нескольких несовпадающих значений из множества. (60187 hits)
#Преобразование целых чисел в битовый массив. (38729 hits)
#Постепенное затемнение. (52172 hits)
#Добавление истории операций(undo&redo) в компонент. (41014 hits)
#Загрузчик классов. (44438 hits)


Главная >> Каталог задач >> Паттерны >> Структурные >>

Приспособленец (Flyweight)

Aвтор:
Дата:
Просмотров: 119023
реализации(java: 9шт...) +добавить

Имя

«Паттерн
Flyweight»

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

Условия, Задача, Назначение

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

Мотивация

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

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

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

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

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

Приспособленец, представляющий букву «а», содержит только соответствующий ей код: ни положение, ни шрифт буквы ему хранить не надо. Клиенты передают приспособленцу всю зависящую от контекста информацию, которая нужна, чтобы он мог изобразить себя. Например, глифу Row известно, где его потомки должны себя показать, чтобы это выглядело как горизонтальная строка. Поэтому вместе с запросом на рисование он может передавать каждому потомку координаты.
Поскольку число различных объектов-символов гораздо меньше, чем число символов в документе, то и общее количество объектов существенно меньше, чем было бы при простой реализации. Документ, в котором все символы изображаются одним шрифтом и цветом, создаст порядка 100 объектов-символов (это примерно равно числу кодов в таблице ASCII) независимо от своего размера. А поскольку в большинстве документов применяется не более десятка различных комбинаций шрифта и цвета, то на практике эта величина возрастет несущественно. Поэтому абстракция объекта становится применимой и к отдельным символам и главное – количество инстанцируемых сущностей уже не зависит от действий пользователя: какие бы документов каких объемов он не создавал – количество экземпляров букв текста будет фиксировано а память будет расходоваться только, по сути, на дополнительные ссылки на объекты.

Признаки применения, использования паттерна Приспособленец (Flyweight)

Эффективность паттерна приспособленец во многом зависит от того, как и где он используется. Применяйте этот паттерн, когда выполнены все нижеперечисленные условия:
  1. В приложении используется большое число объектов и из-за этого накладные расходы на хранение высоки.
  2. Большую часть состояния объектов можно вынести вовне (в ответственность клиентов, которые создают и используют эти объекты).
  3. Многие группы объектов можно заменить относительно небольшим количеством разделяемых объектов, поскольку внешнее состояние вынесено.
  4. Приложение не зависит от идентичности объекта. Поскольку объекты-приспособленцы могут разделяться, то проверка на идентичность возвратит истину для «концептуально» различных объектов (внутреннее состояние объектов же не меняется). Ключевой момент в том, что когда эти объекты запускают свои функции, то с учетом переданной от клиента информации (внешнего состояния) – результат выполнения получения совсем не идентичен другим.

Решение

На следующей диаграмме показано, как приспособленцы разделяются:

Участники паттерна Приспособленец (Flyweight)

  1. Flyweight (Glyph) – приспособленец.
    Объявляет интерфейс, с помощью которого приспособленцы могут получать внешнее состояние или как-то воздействовать на него.
  2. ConcreteFlyweight (Character) - конкретный приспособленец.
    Реализует интерфейс класса Flyweight и добавляет при необходимости внутреннее состояние. Объект класса ConcreteFlyweight должен быть разделяемым. Любое сохраняемое им состояние должно быть внутренним, то есть не зависящим от контекста.
  3. UnsharedConcreteFlyweight (Row, Column) - неразделяемый конкретный приспособленец.
    Не все подклассы Flyweight обязательно должны быть разделяемыми. Интерфейс Flyweight допускает разделение, но не навязывает его. Часто у объектов UnsharedConcreteFlyweight на некотором уровне структуры приспособленца есть потомки в виде объектов класса ConcreteFlyweight, как, например, у объектов классов Row и Column.
  4. FlyweightFactory - фабрика приспособленцев.
    Создает объекты-приспособленцы и управляет ими.
    Обеспечивает должное разделение приспособленцев. Когда клиент запрашивает приспособленца, объект FlyweightFactory предоставляет существующий экземпляр или создает новый, если готового еще нет.
  5. Client – клиент.
    Хранит ссылки на одного или нескольких приспособленцев.
    Вычисляет или хранит внешнее состояние приспособленцев.

Схема использования паттерна Приспособленец (Flyweight)

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

Клиенты не должны создавать экземпляры класса ConcreteFlyweight напрямую, а могут получать их только от объекта FlyweightFactory. Это позволит гарантировать корректное разделение.

Вопросы, касающиеся реализации паттерна Приспособленец (Flyweight)

При реализации приспособленца следует обратить внимание на следующие вопросы:
  1. Вынесение внешнего состояния.
    Применимость паттерна в значительной степени зависит от того, насколько легко можно «очертить» внешнее состояние и вынести его за пределы разделяемых объектов. Вынесение внешнего состояния не уменьшает стоимости хранения, если различных внешних состояний так же много, как и объектов до разделения. Лучший вариант - внешнее состояние вычисляется по объектам с другой структурой, требующей значительно меньшей памяти.
    Например, в нашем редакторе документов мы можем поместить карту с типографской информацией в отдельную структуру, а не хранить шрифт и начертание вместе с каждым символом. Данная карта будет отслеживать непрерывные серии символов с одинаковыми типографскими атрибутами. Когда объект-символ изображает себя, он получает типографские атрибуты от алгоритма обхода. Поскольку обычно в документах используется немного разных шрифтов и начертаний, то хранить эту информацию отдельно от объекта-символа гораздо эффективнее, чем непосредственно в нем.
  2. Управление разделяемыми объектами.
    Так как объекты разделяются, клиенты не должны инстанцировать их напрямую. Фабрика FlyweightFactory позволяет клиентам найти подходящего приспособленца. В объектах этого класса часто есть хранилище, организованное в виде ассоциативного массива (или хеш-таблицы), с помощью которого можно быстро находить приспособленца, нужного клиенту. Так, в примере редактора документов фабрика приспособленцев может содержать внутри себя таблицу, индексированную кодом символа, и возвращать нужного приспособленца по его коду. А если требуемый приспособленец отсутствует, он тут же создается. Разделяемость подразумевает также, что имеется некоторая форма подсчета ссылок или сбора мусора для освобождения занимаемой приспособленцем памяти, когда необходимость в нем отпадает. Однако ни то, ни другое необязательно, если число приспособленцев фиксировано и невелико (например, если речь идет о представлении набора символов кода ASCII). В таком случае имеет смысл хранить приспособленцев в памяти постоянно.

Результаты

При использовании приспособленцев не исключены затраты на передачу, поиск или вычисление внешнего состояния, особенно если раньше оно хранилось как внутреннее. Однако такие расходы с лихвой компенсируются экономией памяти за счет разделения объектов-приспособленцев.
Экономия памяти возникает по ряду причин:
  1. Уменьшение общего числа экземпляров.
  2. Сокращение объема памяти, необходимого для хранения внутреннего состояния.
  3. Вычисление, а не хранение внешнего состояния.

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

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

Пример

Представим себе некоторый простенький компоновщик содержимого web-контента. Html-страница может состоять из огромного количества html-тегов: a, p, div, img и т.д. Если при этом создаются отдельные объекты для каждого тега на странице – при больших объемах обязательно возникнет проблема перерасхода памяти на хранение всех них.
Паттерн-приспособленец помогает решить эту проблему. Выделив общее внутреннее состояние всех этих тегов, а все остальное оставляя на ответственности т.н. «контекста» - организуем «пул» данных тегов. Тем самым при отрисовке каждого тега мы будем иметь лишь ссылку на объект из этого пула всех видов тегов, передавая туда остальные отличающиеся атрибуты тега в виде контекста, такие как например css стиль тега, значение обязательных атрибутов тега и т.д.

Вот как будет выглядеть базовый класс для всех тегов (Flyweight): HtmlTag.

Т.о. все внутреннее состояние тега составляет лишь его название(name), все остальное, внешнее состояние, будет передаваться в контексте при отрисовке (операция Output).

Класс контекста: TagContext.

Как видим – содержит внешнее состояние. Здесь для простоты это всего лишь список css-стилей: CssStyle.

Все используемые на странице теги (ConcreteFlyweights) будут иметь свои классы объектов, наследуемые от базового HtmlTagATag, PTag, ImgTag, DivTag и т.д.

Далее, соответственно, фабрика тегов (FlyweightFactory): TagFactory.

После определения всех необходимых составляющих паттерна, можно представить клиента (Client), который, используя фабрику, просто будет как ему угодно составлять т.н. “layout”(верстка, каркас) html-страницы: Client.

Известные применения паттерна Приспособленец (Flyweight)

Концепция объектов-приспособленцев впервые была описана и использована как техника проектирования в библиотеке Interviews 3.0. Ее разработчики построили мощный редактор документов Doc, чтобы доказать практическую полезность подобной идеи. В Doc объекты-глифы используются для представления любого символа документа. Редактор строит по одному экземпляру глифа для каждого сочетания символа и стиля (в котором определены все графические атрибуты). Таким образом, внутреннее состояние символа состоит из его кода и информации о стиле (индекс в таблицу стилей). Следовательно, внешней оказывается только позиция, поэтому Doc работает быстро. Документы представляются классом Document, который выполняет функции фабрики FlyweightFactory. Измерения показали, что реализованное в Doc разделение символов-приспособленцев весьма эффективно. В типичном случае для документа из 180 тысяч знаков необходимо создать только 480 объектов-символов.

В каркасе ЕТ++ приспособленцы используются для поддержки независимости от внешнего облика. Его стандарт определяет расположение элементов пользовательского интерфейса (полос прокрутки, кнопок, меню и пр., в совокупности именуемых виджетами) и их оформления (тени и т.д.). Виджет делегирует заботу о своем расположении и изображении отдельному объекту Layout. Изменение этого объекта ведет к изменению внешнего облика даже во время выполнения.

Для каждого класса виджета имеется соответствующий класс Layout (например, ScrollbarLayout, MenubarLayout и т.д.). В данном случае очевидная проблема состоит в том, что удваивается число объектов пользовательского интерфейса, ибо для каждого интерфейсного объекта есть дополнительный объект Layout. Чтобы избавиться от расходов, объекты Layout реализованы в виде приспособленцев. Они прекрасно подходят на эту роль, так как заняты преимущественно определением поведения и им легко передать тот небольшой объем внешней информации о состоянии, который необходим для изображения объекта.
Объекты Layout создаются и управляются объектами класса Look. Класс Look - это абстрактная фабрика, которая производит объекты Layout с помощью таких операций, как GetButtonLayout, GetMenuBarLayout и т.д. Для каждого стандарта внешнего облика у класса Look есть соответствующий подкласс (MotifLook, OpenLook и т.д.).
Кстати говоря, объекты Layout - это, по существу, стратегии (см. паттерн стратегия). Таким образом, мы имеем пример объекта-стратегии, реализованный в виде приспособленца.

Родственные паттерны

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

Реализации:

java(9)   +добавить

1) HtmlTag.java на java, code #470[автор:this]
2) TagContext.java на java, code #471[автор:this]
3) CssStyle.java на java, code #472[автор:this]
4) ATag.java на java, code #473[автор:this]
5) PTag.java на java, code #474[автор:this]
6) ImgTag.java на java, code #475[автор:this]
7) DivTag.java на java, code #476[автор:this]
8) TagFactory.java на java, code #477[автор:this]
9) Client.java на java, code #478[автор:this]