Bridge Pattern - преимущество компиляции в Java?

Question

Об этом говорится в Шаблоны проектирования - элементы многоразового объектно-ориентированного программного обеспечения книга:

В ситуациях, когда существует только одна реализация (один к одному), создание абстрактный класс разработчика не нужен. Это вырожденный случай мостового рисунка; есть отношения один-к-одному между Абстракция и исполнитель. Тем не менее, это разделение все еще полезно, когда изменение в реализации класса не должно влиять его существующие клиенты - то есть они не должны быть перекомпилировано, только что перекомпоновано.

Я сомневаюсь в преимуществах времени компиляции, потому что не могу представить себе случай в Java, когда изменение в реализации заставляет перекомпилировать его суперкласс (в данном случае абстрактное).

Например, если у нас X расширяет Y, а клиент делает:

Y y = new X();  

Изменение X не означает перекомпиляцию Y (конечно, если мы не хотим изменять сигнатуры метода X)

То же самое при использовании Bridge Pattern:

YAbstraction yabstraction = new YRefinedAbstraction(new XImplementor());

Изменение XImplementor не означает перекомпиляцию YAbstraction.

Так что, по моему мнению, это преимущество не имеет места в Java и не требует однозначного => шаблона моста.

Возможно, изменение в подклассе заставляет суперкласс перекомпилироваться на других языках? как SmallTalk и C ++?

Ваше мнение?

Answer 1

В шаблоне моста у вас есть две иерархии классов: одна для абстракции (например, окно с производными классами, такими как DialogWindow и IconWindow) и одна для исполнителя (например, WindowImpl с производными классами, такими как XWindowImpl и PMWindowImpl).Интерфейс разработчика должен быть скрыт от клиентов Абстракции.Как правило, Implementor предоставляет низкоуровневые примитивы, а Abstraction создает высокоуровневые операции в терминах этих примитивов, поэтому в хорошо выстроенной системе клиентам не нужно видеть низкоуровневый интерфейс, предлагаемый Implementor.Если однажды окажется, что интерфейс, предлагаемый WindowImpl, недостаточно универсален для размещения нового XYZWindowImpl, вы сохраняете свободу изменять его, поскольку WindowImpl никогда не должен использоваться непосредственно вашими клиентами, а только Window и его подклассами.Таким образом, изменение интерфейса WindowImpl может потребовать внесения изменений в Window, но не будет распространяться на клиентов.Кроме того, часто скрывают Реализатор за Абстрактной Фабрикой, которая используется для конфигурирования моста.

Преимущество описанного вами паттерна Моста зависит от сокрытия интерфейса Реализатора от клиентов Абстракции.В C ++ вы можете легко скрыть интерфейс Implementor, просто не предоставив заголовочный файл.В Java вы можете сделать Implementor абстрактным классом с закрытыми членами пакета.

В C ++ клиенты абстракции не нужно перекомпилировать, только перекомпоновать.В Java вместо связывания у вас есть загрузка классов и, следовательно, все, что вам нужно сделать, это перезагрузить приложение с новыми настройками и новым файлом jar.

Представьте, например, ситуацию, когда параметр командной строки или переменная окруженияиспользуется абстрактной фабрикой для настройки моста с правильным видом ConcreteImplementor.В этом случае вам просто нужно перезагрузить приложение с новыми параметрами командной строки / среды и новым файлом jar, содержащим новый ConcreteImplementor.Вы можете сделать это без перекомпиляции клиентского кода.

Таким образом, чтобы дать прямой ответ на ваш вопрос: также в Java шаблон Bridge имеет преимущество, описанное в вопросе.Возможно, даже в большей степени, если учесть тот факт, что перепривязки никогда не происходит.

Answer 2

Java не имеет «связывания» так же, как C / C ++.Тем не менее, я думаю, что концепция все еще применима: если класс реализации находится в отдельной библиотеке (файл .jar) от абстракции, то вам не нужно перепаковывать файл .jar, содержащий абстракцию.Это может упростить обслуживание сложной системы.