Коли використання Flyweight стає неефективним?
Використання Flyweight (Пристосуванець) стає неефективним, коли зовнішнього стану занадто багато або спільні дані не повторюються достатньо часто - тоді витрати на керування шаблонами перевищують вигоду.
1. Коли більшість об'єктів унікальні
Якщо об'єкти майже не мають спільного стану (усі відрізняються за десятками параметрів), створення і зберігання пулу flyweight-ів не дає економії, а лише додає накладні витрати.
Приклад: якщо в кожного дерева унікальна текстура і колір, зберігання "спільних"
TreeTypeне має сенсу.
2. Коли зовнішнього стану занадто багато
Flyweight вимагає, щоб унікальні дані (координати, ім'я, стан) передавалися ззовні. Якщо цих даних багато, то:
- код стає складнішим - потрібно передавати довгі аргументи;
- об'єкти перестають бути "легкими";
- продуктивність падає через часті звернення до зовнішніх структур.
3. Висока вартість пошуку і зберігання в пулі
Якщо кеш занадто великий (десятки тисяч записів), пошук потрібного flyweight у колекції (особливо за поганого ключа) може стати дорожчим, ніж створення нового об'єкта.
4. Проблеми з потокобезпекою
Розділювані flyweight-об'єкти використовуються багатьма потоками, і за неправильної синхронізації виникають гонки і блокування, що уповільнюють систему.
5. Зниження читабельності і зростання складності
Передача зовнішнього стану в усі виклики ускладнює код і робить його менш очевидним:
treeType.draw(x, y, rotation, windSpeed, humidity);Іноді простіше зберігати все в одному об'єкті.
Висновок
Flyweight неефективний, коли:
- частка спільних даних мала,
- керування пулом складніше, ніж створення об'єктів,
- занадто багато зовнішнього стану або потоків.
Підсумок: Пристосуванець корисний за масового дублювання даних, але в системах з високою унікальністю об'єктів він лише ускладнює архітектуру і знижує продуктивність.
Коротка відповідь
Для співбесідиКоротка відповідь допоможе вам впевнено відповідати на цю тему під час співбесіди.