Интересный паттерн API

Question

При изучении исходного кода Neo4J я заметил, что они используют очень интересный шаблон для отделения интерфейса от реализации.Существует интерфейс Node , который реализуется только классом NodeProxy .NodeProxy, в свою очередь, делегирует NodeImpl , который, как вы думаете, тоже реализует Node, но это не так.NodeImpl имеет те же методы с той же сигнатурой и является вспомогательной реализацией Node, но он не реализует Node.Я использовал шаблон прокси раньше, но сделал бы NodeImpl для реализации Node, как это делает NodeProxy.Любые идеи о преимуществах, которые дает этот шаблон?

Редактировать 1: Благодаря комментарию Циркеля я теперь знаю, что он называется Шаблон моста , и основная цель состоит в том, чтобы "отделить абстракцию от его реализации,что оба могут варьироваться независимо друг от друга ", интересно.

Answer 1

Если вы посмотрите на NodeImpl немного более подробно, вы увидите, что методы там, соответствующие методам Node, имеют разные сигнатуры - они дополнительно принимают аргумент NodeManager.

Только это делаетдля них невозможно реализовать интерфейс Node.

Затем NodeProxy поддерживает ссылку на NodeManager, который он затем может передать объектам NodeImpl.

Answer 2

Суть в том, что он заставляет вас проходить через NodeProxy, а не работать с NodeImpl напрямую. Я не достаточно знаком с Neo4J, чтобы сказать, почему было бы выгодно делать это в этом контексте. Возможно, NodeProxy оснащен дополнительным поведением, которого нет у NodeImpl.

Answer 3

Основным эффектом этой реализации будет то, что зависимости будут отменены. Если вы позволите NodeImpl реализовать Node, то NodeImpl будет зависеть от Node. Представляя NodeProxy, вы позволяете NodePoxy зависеть от NodeImpl, в то время как NodeImpl не зависит ни от чего. Это может быть преимуществом или необходимостью по какой-то причине в конкретном контексте.