Обзор темы [Шаблоны проектирования]

Затем: МотивацияНазначение

Отделяет абстракцию от ее реализации так, чтобы две эти части могли изменяться независимо.

Затем: СтруктураМотивация

Когда абстракция может иметь одну из нескольких возможных реализаций, обычный способ их размещения заключается в использовании наследования. Абстрактный класс определяет интерфейс абстракции, а конкретные подклассы реализуют его различными способами. Но этот подход не всегда достаточно гибок. Наследование связывает реализацию с абстракцией постоянно, что затрудняет их изменение, расширяемость, и возможность многократно использования абстракции и реализации независимо.

Рассмотрим реализацию переносимой абстракции Window в комплекте инструментальных средств интерфейса пользователя. Эта абстракция должна предоставлять нам возможность писать приложения, которые работают и под XWindows и под IBM Presentation Manager. Используя наследование, мы можем определить абстрактный класс Window и подклассы XWindow и PMWwindow, которые реализуют интерфейс Window для различных платформ. Но этот подход имеет два недостатка:

  1. Неудобно расширить абстракцию Window, чтобы создавать различные виды окон или новых платформ. Вообразите подкласс IconWindow, которое специализирует абстракцию Window для иконок. Чтобы поддерживать IconWindows для обеих платформ, мы должны реализовать два новых класса, XIconWindow и PMIconWindow. Что ещё хуже, мы должны определить по два класса для каждого вида окна. Обеспечение третьей платформы требует другого, нового подкласса Window для каждого вида окна.

 

  1. Это делает клиентский код зависимым от платформы. Всякий раз, когда клиент создает окно, это instantiates конкретный класс, который имеет специфическую реализацию. Например, создавая объект XWindow связывает абстракцию Окна с X реализацией Окна, которая делает клиента кодозависимым на X реализации Окна. Это, в свою очередь, делает это тяжелее к порту клиентским кодом на другие платформы.

Клиент должен иметь возможность создавать окно без перехода к конкретной реализации. Только реализация окна должна зависеть от платформы, на которой приложение выполняется. Следовательно клиентский код должен инстанциировать окна без намека на специфические платформы.

Шаблон Bridge решает эти проблемы, помещая абстракцию Window и ее реализацию в отдельных иерархиях класса. Имеется одна иерархия класса для интерфейсов окна (Window, IconWindow, TransientWindow) и отдельная иерархия для специфических для платформы реализаций окна, с WindowImp как его корень. Подкласс XWindowImp, например, обеспечивает реализацию основанную на XWindows.

Все операции на подклассах Window выполнены в терминах абстрактных операций из интерфейса WindowImp. Обратите внимание на связь между Window и WindowImp - это и есть мост (bridge), потому что она позволяет им измениться независимо.

 

Затем: Составные частиСтруктура

Составные части