Page 53 - 4190

 створення чи знищення об'єкта є дуже затратною операцією.
Пул об'єктів може працювати як з інтерфейсами, так і з конкрет-
ними реалізаціями. Все залежить від архітектури системи, що розроб-
ляється та розв'язуваних задач.

Можна побачити сумісне використання Пула об'єктів та інших
шаблонів проектування. Наприклад, для створення об'єктів в конкре-
тному стані можна використати Прототип. А за допомогою Одинака

— створити єдиний екземпляр Пула в системі.
Поганою практикою вважається приховування Пула за іншими
шаблонами проектування. Розробник, який використовує такий під-
хід, не очікує вимоги повернення об'єктів, наприклад, Фабричного

методу. А без повернення об'єктів сам Пул стає непотрібним. У тако-
му випадку, правильним рішенням буде відділити реалізацію класів,
що створюють об'єкти.

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

ковий стан (скидання). Наявність об'єктів у невизначеному стані пе-
ретворює Пул в «об'єктну клоаку» (object cesspool). Повторне викори-
стання може стати причиною витоку конфіденційної інформації. То-

му обов'язково необхідно зчищати поля з секретними даними при
скиданні, а самі дані — знищувати. Можлива ситуація, коли в Пулі не
залишиться вільних об'єктів. У такому випадку реакція на запит може
бути такою:

 збільшення розміру пула;
 відмова у видачі об'єкта;
 становлення в чергу і очікування звільнення об'єкта.

UML-діаграма класів патерну Object Pool зображена на рисунку 5.7.

Рисунок 5.7 – UML-діаграма класів патерну Object Pool

 Reusable – екземпляри класів у цій ролі взаємодіють з іншими
об'єктами впродовж обмеженого часу, а потім вони більше не потріб-
ні для цієї взаємодії;

53