→ Пошук по сайту       Увійти / Зареєструватися
Знання Патерни Структурні патерни — Structural patterns

7. Міст — Bridge

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, яка якраз і є своєрідним мостом до реалізації.
Ще раз замислимося над означенням і прикладом. Методи BuildFoundation та BuildRoof повністю знаходяться в абстракції і можуть змінюватися, навіть метод BuildRoom і той може змінитися, проте він не виконує повноцінну роботу – він надіється на імплементацію, яка прийде по мосту і зробить потрібну роботу потрібним чином.

Уривок коду 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. Міст

По матеріалам книги Андрія Будая "Дизайн патерни – просто, як двері". Матеріал розміщується за домовленістю з автором.
Робота представлена за умовами ліцензії Creative Commons Attribution-NonCommercial 3.0 Unported License.

загрузка...
Сторінки, близькі за змістом