6. Адаптер — Adapter
ADO в Delphi AJAX Android C++ CakePHP CMS COM CSS Delphi Flash Flex HTML Internet Java JavaScript MySQL PHP RIA SCORM Silverlight SQL UML XML Бази даних Веб-розробка Генетичні алгоритми ГІС Гітара Дизайн Економіка Інтелектуальні СДН Колір Масаж Математика Медицина Музика Нечітка логіка ООП Патерни Подання знань Розкрутка сайту, SEO САПР Сесії в PHP Системне програмування Системний аналіз Тестологія Тестування ПЗ Фреймворки Штучний інтелект
|
6. Адаптер — AdapterЗ деяких причин я дуже довго думав над тим, який же може бути хороший приклад для Адаптера. Можна навести приклад, коли є операції, які так і називаються: ОпераціяА та ОпА, або придумати складний приклад з великою кількістю методів і пропертів в класі, що адаптується... Але весь цей час в думках у мене крутилася така штукенція, яку ми соваємо у розетку, коли вона вузька, ще СРСР-рівська, а ми хочемо запхати шнур для живлення ноутбука із товстою вилкою. Майже, як на ілюстрації, але не настільки жорстока. Отож, у нас є вилка від зарядного пристрою, яка підходить в широкі роз’єми. В одній із квартир у нас все сучасне, тому NewElectricitySystem має метод MatchWideSocket, яким ми просто можемо скористатися. В іншій квартирі у нас проблемки, тому OldElectricitySytem має тільки метод MatchThinSocket. Нажаль ми не можемо собі дозволити взяти дрель і роздовбати отвори в розетці. Натомість ми купуємо адаптер, який надає можливість користуватися тією ж функціональністю споживання електричного струму, але із старої системи. Адаптер надає можливість користуватися об’єктом, який не є прийнятним у нашій системі і який не можна змінити. Ми адаптуємо його функціональність через інший, відомий нашій системі, інтерфейс. Уривок коду 6.1. Читаємо код і вникаємоAdapter : INewElectricitySystem { // Але всередині він таки знає, що коїлося в СРСР private readonly OldElectricitySystem _adaptee; public Adapter(OldElectricitySystem adaptee) { _adaptee = adaptee; } // А тут відбувається вся магія - // наш адаптер «перекладає» // функціональність із нового стандарту на старий public string MatchWideSocket() { // Якщо б була різниця в напрузі (не 220V) // то тут ми б помістили трансформатор return _adaptee.MatchThinSocket(); } } class ElectricityConsumer { // Зарядний пристрій розуміє тільки нову систему public static void ChargeNotebook(INewElectricitySystem electricitySystem) { Console.WriteLine(electricitySystem.MatchWideSocket()); } } public class AdapterDemo { public static void Run() { // 1) // Ми можемо користуватися новою системою без проблем var newElectricitySystem = new NewElectricitySystem(); ElectricityConsumer.ChargeNotebook(newElectricitySystem); // 2) // Ми повинні адаптуватися до старої системи, використовуючи адаптер var oldElectricitySystem = new OldElectricitySystem(); var adapter = new Adapter(oldElectricitySystem); ElectricityConsumer.ChargeNotebook(adapter); } }// Система яку будемо адаптовувати class OldElectricitySystem { public string MatchThinSocket() { return "220V"; } } // Широковикористовуваний інтерфейс нової системи (специфікація до квартири) interface INewElectricitySystem { string MatchWideSocket(); } // Ну і власне сама розетка у новій квартирі class NewElectricitySystem : INewElectricitySystem { public string MatchWideSocket() { return "220V"; } } // Адаптер назовні виглядає як нові євроразетки, шляхом наслідування прийнятного у // системі інтерфейсу class Попрошу ще раз повернутися до коду і переконатися, що ви прочитали усі коментарі, а взаємодія між класами була зрозуміла. Для кращого засвоєння, візьміть ручку і на будь-якому «огризку» паперу намалюйте UML до цієї реалізації патерну Адаптер, а потім узагальніть. Насправді в реалізації не є обов’язковою композиція adaptee. Також наш клас Adapter міг би одночасно реалізовувати два інтерфейси — нової і старої системи. А зробивши два конструктори (а чому б і ні?), ми б могли одного разу створити його на базі нової, а іншого — на базі старої системи. Це б дозволило використовувати його в обидва боки. Натиснувши собі якусь кнопку, ваш адаптер перетворюється «шиворіт-на-виворіт».
По матеріалам книги Андрія Будая "Дизайн патерни – просто, як двері". Матеріал розміщується за домовленістю з автором.
Зверніть увагу на додаткові посиланняЯкщо вас цікавить...Головний розділСторінки, близькі за змістомзагрузка...
|
Сторінки, близькі за змістом Шаблони проектування програмного забезпечення (англ. software design patterns) — ефективні способи вирішення задач проектування програмного забезпечення. Шаблон не є закінченим зразком, який можна безпосередньо транслювати в програмний код. Об'єктно-орієнтований шаблон найчастіше є зразком вирішення проблеми і відображає відношення між класами та об'єктами, без вказівки на те, як буде зрештою реалізоване це відношення. |
Copyright © 2008—2024 Портал Знань.
При використанні матеріалів посилання, для інтернет-ресурсів — гіперпосилання, на Znannya.org обов'язкове.
Зв'язок
|
НТУУ "КПІ" Інженерія програмного забезпечення КПІ Лабораторія СЕТ |
|