7. Міст — Bridge
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 Системне програмування Системний аналіз Тестологія Тестування ПЗ Фреймворки Штучний інтелект
|
7. Міст — BridgeУявімо, що ви володієте будівельною компанією, яка будує дачні будинки і житлові масиви. Зазвичай будівлі є двох типів - або з цегли, або з бетонних плит. Оскільки ви бос, то ви вирішили поділити всіх ваших робітників на команди, які будуть вміти робити одні і ті ж операції: BuildFoundation, BuildRoom, BuildRoof. Так як будівлі є двох типів, то вам прийдеться тримати два типи різних бригад. Одного разу виявилося, що будівлі можуть бути побудовані із бетонних і цегляних стін одночасно. Так як у кожній із бригад вміли працювати тільки із одним типом стін, ви були змушені переміщати цілі бригади із одного закутка міста в інший. Прямо таки переселення народів. Працівники починають жалітися і пропонують вирішення проблеми. Пропозиція полягає у виділенні двох маленьких бригад, які спеціалізуються в будуванні кімнат або із бетонних або із цегляних стін. Таким чином тільки ці бригади і можна буде перевозити із одного закутка міста в інше, замість того, щоб мати окремі великі команди. Міст дозволяє розділити імплементацію від її абстракції, таким чином реалізація може бути змінена окремо від абстракції, оскільки вона не наслідується від неї напряму. Іншими словами, наш інтерфейс IBuildingCompany може мати дві конкретні реалізації, такі як NearSeeBuildingCompany та CityBuildingCompany, кожна із яких, напевно, якось по своєму робить фундамент та дах, оскільки грунт інший і погода також, але в той же час ми можемо просто і легко змінити реалізацію бригади побудови стін - WallCreator для будь-якої із компаній, щоб будувати або цегляні або бетонні стіни. Уривок коду 7.1. Гляньмо на BuildingCompany
interface IBuldingCompany
{
void BuildFoundation();
void BuildRoom();
void BuildRoof();
IWallCreator WallCreator { get; set; }
}
class BuldingCompany : IBuldingCompany
{
public void BuildFoundation()
{
Console.WriteLine("Foundation is built.{0}", Environment.NewLine);
}
public void BuildRoom()
{
WallCreator.BuildWallWithDoor();
WallCreator.BuildWall();
WallCreator.BuildWallWithWindow();
WallCreator.BuildWall();
Console.WriteLine("Room finished.{0}", Environment.NewLine);
}
public void BuildRoof()
{
Console.WriteLine("Roof is done.{0}", Environment.NewLine);
}
public IWallCreator WallCreator { get; set; }
}
І що тут цікавого? Відповідь — властивість WallCreator, яка якраз і є своєрідним мостом до реалізації. Уривок коду 7.2. Глянемо на "міст" в дії
// Ми маємо дві бригади – одна працює із цеглою, інша із бетоном
var brickWallCreator = new BrickWallCreator();
var conctreteSlabWallCreator = new ConcreteSlabWallCreator();
var buildingCompany = new BuldingCompany();
buildingCompany.BuildFoundation();
buildingCompany.WallCreator = conctreteSlabWallCreator;
buildingCompany.BuildRoom();
// Компанія може легко переключитися на іншу команду, яка буде будувати
// стіни із інших матеріалів
buildingCompany.WallCreator = brickWallCreator;
buildingCompany.BuildRoom();
buildingCompany.BuildRoom();
buildingCompany.BuildRoof();
Хіба це не чудово? Вивід, я припускаю, є інтуїтивним, проте оскільки я не наводив реалізацій класів BrickWallCreator та ConcreteSlabWallCreator подивимося на нього. Вивід:
Foundation is built.
Concrete slab wall with door.
Concrete slab wall.
Concrete slab wall with window.
Concrete slab wall.
Room finished.
Brick wall with door.
Brick wall.
Brick wall with window.
Brick wall.
Room finished.
Brick wall with door.
Brick wall.
Brick wall with window.
Brick wall.
Room finished.
Roof is done.
UML-діаграма зображає структуру цього дизайн патерну. Дивлячись на діаграму, стає зрозумілою його назва.
UML-діаграма 5. Міст
По матеріалам книги Андрія Будая "Дизайн патерни – просто, як двері". Матеріал розміщується за домовленістю з автором.
Зверніть увагу на додаткові посиланняЯкщо вас цікавить...Головний розділСторінки, близькі за змістомзагрузка...
|
Сторінки, близькі за змістом Шаблони проектування програмного забезпечення (англ. software design patterns) — ефективні способи вирішення задач проектування програмного забезпечення. Шаблон не є закінченим зразком, який можна безпосередньо транслювати в програмний код. Об'єктно-орієнтований шаблон найчастіше є зразком вирішення проблеми і відображає відношення між класами та об'єктами, без вказівки на те, як буде зрештою реалізоване це відношення. |
Copyright © 2008—2024 Портал Знань.
При використанні матеріалів посилання, для інтернет-ресурсів — гіперпосилання, на Znannya.org обов'язкове.
Зв'язок
|
НТУУ "КПІ" Інженерія програмного забезпечення КПІ Лабораторія СЕТ |
|