Читати книгу - "Занурення в патерни проектування, Олександр Швець"
Шрифт:
Інтервал:
Добавити в закладку:
info = service.getVideoInfo(id)
// Відобразити сторінку відеоролика.
method renderListPanel() is
list = service.listVideos()
// Відобразити список превью відеороликів.
method reactOnUserInput() is
renderVideoPage()
renderListPanel()
// Конфігураційна частина програми створює та передає клієнтам
// об'єкт замісника.
class Application is
method init() is
YouTubeService = new ThirdPartyYouTubeClass() YouTubeProxy = new CachedYouTubeClass(YouTubeService) manager = new YouTubeManager(YouTubeProxy)
manager.reactOnUserInput() Застосування
Лінива ініціалізація (віртуальний проксі). Коли у вас є важкий об’єкт, який завантажує дані з файлової системи або бази даних.
Замість того, щоб завантажувати дані відразу після старту програми, можна заощадити ресурси й створити об’єкт тоді, коли він дійсно знадобиться.
Захист доступу (захищаючий проксі). Коли в програмі є різні типи користувачів, і вам хочеться захистити об’єкт від неавторизованого доступу. Наприклад, якщо ваші об’єкти — це важлива частина операційної системи, а користувачі — сторонні програми (корисні чи шкідливі).
Проксі може перевіряти доступ під час кожного виклику та передавати виконання службовому об’єкту, якщо доступ дозволено.
Локальний запуск сервісу (віддалений проксі). Коли справжній сервісний об’єкт знаходиться на віддаленому сервері.
У цьому випадку замісник транслює запити клієнта у виклики через мережу по протоколу, який є зрозумілим віддаленому сервісу.
Логування запитів (логуючий проксі). Коли потрібно зберігати історію звернень до сервісного об’єкта.
Замісник може зберігати історію звернення клієнта до сервісного об’єкта.
Кешування об’єктів («розумне» посилання). Коли потрібно кешувати результати запитів клієнтів і керувати їхнім життєвим циклом.
Замісник може підраховувати кількість посилань на сервісний об’єкт, які були віддані клієнту та залишаються активними. Коли всі посилання звільняться, можна буде звільнити і сам сервісний об’єкт (наприклад, закрити підключення до бази даних).
Крім того, Замісник може відстежувати, чи клієнт не змінював сервісний об’єкт. Це дозволить повторно використовувати об’єкти й суттєво заощаджувати ресурси, особливо якщо мова йде про великі «ненажерливі» сервіси.
Кроки реалізаціїВизначте інтерфейс, який би зробив замісника та оригінальний об’єкт взаємозамінними.
Створіть клас замісника. Він повинен містити посилання на сервісний об’єкт. Частіше за все сервісний об’єкт створюється самим замісником. У рідкісних випадках замісник отримує готовий сервісний об’єкт від клієнта через конструктор.
Реалізуйте методи замісника в залежності від його призначення. У більшості випадків, виконавши якусь корисну роботу, методи замісника повинні передати запит сервісному об’єкту.
Подумайте про введення фабрики, яка б вирішувала, який з об’єктів створювати: замісника або реальний сервісний об’єкт. Проте, з іншого боку, ця логіка може бути вкладена до створюючого методу самого замісника.
Подумайте, чи не реалізувати вам ліниву ініціалізацію сервісного об’єкта при першому зверненні клієнта до методів замісника.
Переваги та недоліки Дозволяє контролювати сервісний об’єкт непомітно для клієнта. Може працювати, навіть якщо сервісний об’єкт ще не створено. Може контролювати життєвий цикл службового об’єкта. Ускладнює код програми внаслідок введення додаткових класів. Збільшує час отримання відклику від сервісу. Відносини з іншими патернамиАдаптер надає класу альтернативний інтерфейс. Декоратор надає розширений інтерфейс. Замісник надає той самий інтерфейс.
Фасад схожий на Замісник тим, що замінює складну підсистему та може сам її ініціалізувати. Але, на відміну від Фасаду, Замісник має такий самий інтерфейс, що і його службовий об’єкт, завдяки чому їх можна взаємозаміняти.
Декоратор та Замісник мають схожі структури, але різні призначення. Вони схожі тим, що обидва побудовані на композиції та делегуванні роботи іншому об’єкту. Патерни відрізняються тим, що Замісник сам керує життям сервісного об’єкта, а обгортання Декораторів контролюється клієнтом.
Список поведінкових патернів проектування, які вирішують завдання ефективної та безпечної взаємодії між об'єктами програми.
Ланцюжок обов'язків Chain of Responsibility Дає змогу передавати запити послідовно ланцюжком обробників. Кожен наступний обробник вирішує, чи може він обробити запит сам і чи варто передавати запит далі ланцюжком.!Увага!
Сайт зберігає кукі вашого браузера. Ви зможете в будь-який момент зробити закладку та продовжити читання книги «Занурення в патерни проектування, Олександр Швець», після закриття браузера.