Шаблони проектування, що породжують - Об'єктний пул

шаблоны проектирования, object, pool

Голи

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

Проблеми

Пули об'єктів (інакше звані пулами ресурсів) використовуються управління кешуванням об'єктів. Клієнт, який має доступ до пулу об'єктів, може уникнути створення нових об'єктів, просто попросивши пул про новий об'єкт, який вже було створено. Як правило, пул буде пулом, що росте, тобто сам пул буде створювати нові об'єкти, якщо пул порожній. Також ми можемо мати пул, який обмежує кількість створених об'єктів.

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

Обговорення

Пул об'єктів дозволяє іншим об'єктам «перевіряти» об'єкти зі свого пулу, коли ці об'єкти більше не потрібні їхнім процесам, вони повертаються в пул для повторного використання.

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

Структура

Загальна ідея шаблону пула з'єднань полягає в тому, що якщо екземпляри класу можуть бути повторно використані, ви уникаєте створення екземплярів класу, повторно використовуючи їх.

• Reusable . Примірники класів у цій ролі взаємодіють з іншими об'єктами протягом обмеженого періоду часу, потім вони більше не потрібні для цієї спільної роботи
• Client . Примірники класів у цій ролі використовують багаторазові об'єкти.
• ReusablePool. Примірники класів у цій ролі керують багаторазовими об'єктами для використання об'єктами Client.

Зазвичай бажано зберегти всі об'єкти, які повторно використовуються, які в даний час не використовуються в одному пулі об'єктів, щоб вони могли керуватися однією послідовною політикою. Тому клас ReusablePool призначений для Сінглетон класу. Його конструктор(и) є приватним, що змушує інші класи викликати метод getInstance для отримання одного екземпляра класу ReusablePool .

Об'єкт Client викликає метод acquireReusable об'єкта ReusablePool , коли потрібен об'єкт багаторазового використання. Об'єкт ReusablePool підтримує колекцію об'єктів багаторазового використання. Він використовує колекцію об'єктів, що повторно використовуються, щоб містити пул повторно використовуваних об'єктів, які в даний час не використовуються.

Якщо в пулі є об'єкти багаторазового використання, коли викликається метод acquireReusable , він видаляє об'єкт Reusable з пулу і повертає його. Якщо пул порожній, метод acquireReusable створює об'єкт повторного використання, якщо це можливо. Якщо метод acquireReusable не може створити новий об'єкт багаторазового використання, він чекає, поки об'єкт колекції повторно не повернеться до колекції.

Об'єкти Client передають об'єкт багаторазового використання методом releaseReusable у ReusablePool , коли вони припинили роботу з об'єктом. Метод releaseReusable повертає об'єкт багаторазового використання в пул повторно використовуваних об'єктів, які не використовуються.

У багатьох додатках у шаблоні проектування пул об'єктів існують причини обмеження загальної кількості об'єктів багаторазового використання, які можуть існувати. У таких випадках об'єкт ReusablePool, який створює об'єкти повторного використання, несе відповідальність за те, що він не створює більше об'єктів, ніж зазначена максимальна кількість об'єктів, що повторно використовуються. Якщо об'єкти ReusablePool несуть відповідальність за обмеження кількості об'єктів, що створюються, то клас ReusablePool матиме метод для вказівки максимальної кількості об'єктів, які будуть створені. Цей метод вказаний на наведеній вище діаграмі як setMaxPoolSize.

Приклад

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

Контрольний список

1. Створити клас ObjectPool з private масивом об'єктів усередині
2. Створити acquire та release методи
3. Переконайтеся, що ObjectPool працюватиме як синглетон

Емпіричні правила

• Шаблон Factory Method може використовуватись для інкапсуляції логіки створення об'єктів. Проте після створення він не керує ними, шаблон пула об'єктів відстежує створені ним об'єкти.
• Спів об'єктів зазвичай реалізується як Сінглетон