- 1. Голи
- 2. Проблеми
- 3.
- 4. Обговорення
- 5. Структура
- 6. Приклад
- 7. Контрольний список
- 8. Емпіричні правила
Голи
- Використання загального доступу для ефективного використання великої кількості об'єктів.
- Стратегія GUI Motif із заміни великовагових віджетів легкими віджетами.
Проблеми
Проектування об'єктів до найнижчих рівнів «гранулярності» системи забезпечує оптимальну гнучкість, але може бути неприйнятно дорогим з погляду продуктивності та використання пам'яті.
Обговорення
Шаблон Flyweight описує, як обмінюватися об'єктами, щоб їх використання можна було реалізувати за тонкої деталізації без надмірних накладних витрат. Кожен об'єкт "Flyweight" ділиться на дві частини: залежну від стану (зовнішню) частину та незалежну від стану (внутрішню) частину. Внутрішній стан зберігається (спільно використовується) в об'єкті Flyweight. Зовнішній стан зберігається або обчислюється клієнтськими об'єктами та передається Flyweight під час його виконання.
Ілюстрацією цього підходу були віджети Motif, які були перероблені як легкі віджети. Тоді як віджети досить «розумні», щоб працювати самостійно; легкі віджети існують у залежному зв'язку з віджетами диспетчера макетів. Кожен менеджер компонування надає залежну від контексту обробку подій, управління об'єктами та сервіси ресурсів для своїх легкофесних віджетів, і кожен легковажний віджет несе відповідальність лише за незалежний від контексту стан та поведінку.
Структура
Flyweights зберігаються у репозиторії Factory. Клієнт стримує себе від створення Flyweights безпосередньо та запитує їх у Factory. Кожен літнійоб'єкт не може стояти сам по собі. Будь-які атрибути, які могли б унеможливити спільне використання, повинні надаватися клієнтом щоразу, коли робиться запит на Flyweight. Якщо контекст піддається «економії» (тобто Клієнт може легко обчислити або знайти необхідні атрибути), тоді шаблон Flyweight пропонує підходящий під контекст результат.
Класи Ant, Locust та Cockroach можуть бути «легкими», тому що їхній конкретний стан екземпляра був деінкапсульований або екстерналізований і повинен бути наданий клієнтом.
Приклад
Flyweight використовує загальний доступ для ефективного використання великої кількості об'єктів. Сучасні веб-браузери використовують цей метод для запобігання завантаженню однакових зображень двічі. Коли браузер завантажує веб-сторінку, він переглядає усі зображення на цій сторінці. Браузер завантажує все нові зображення з Інтернету та поміщає їх у внутрішній кеш. Для завантажених зображень створюється flyweight об'єкт, який має деякі унікальні дані, такі як позиція всередині сторінки.
Контрольний список
- Переконайтеся, що накладні витрати на об'єкт – це проблема, яка потребує уваги, і клієнт цього класу може виправити ситуацію.
- Розділіть стан цільового класу на: внутрішній стан та зовнішній стан.
- Видаліть зовнішній стан з атрибутів класу і додайте до нього список аргументів, що викликають, для порушених методів.
- Створіть фабрику, яка може кешувати та повторно використовувати існуючі екземпляри класів.
- Клієнт повинен використовувати Factory замість оператора new для запиту об'єктів.
- Клієнт повинен шукати або обчислювати стан, що не є внутрішньою частиною об'єкта, та надавати цей стан методам класу.
Емпіричні правила
- У той час як Flyweight показує, як зробити багато маленьких об'єктів, Facade показує, як зробити один об'єкт, який представляє цілу підсистему.
- Flyweight часто комбінується з Composite для реалізації загальних нод списку.
- Символи терміналу в абстрактному синтаксичному дереві інтерпретатора можуть використовуватися як Flyweight.
- Flyweight пояснює, коли та як об'єкти State можуть використовуватися спільно.
