Pull to refresh

Comments 11

спасибо за материал. небольшое предложение — обращаться для получения proxy не напрямую, а через метод «ленивой инициализации» — getProxy(), тогда не надо будет везде вставлять проверку if (proxy == null)
хотя нет, не внимательно посмотрел код, так что мое предложение неверно
Мне кажется, очень мало раскрыто по использованию данного шаблона. А ведь это один из самых популярных в EJB-технологии. По сути все EJB сделаны в той или иной мере на основе данного подхода.

1) Proxy также (и, наверно, в основном) используются для оборачивания основного объекта некоторой оболочкой, контролирующей его работу. Например, оборачиванием каждого вызова в проверку и открытие транзакции, включение профайлинга и т.д., проверку наличия security credentials и прав доступа на объект. При этом метод исходного объекта, обычно, вызывается «без купюр» — то есть не происходит модификации аргументов вызова или результатов (кроме уже их оборачивания в прокси).

Кстати, использование proxy == null / getProxy() является примером т.н. LazyProxy, являющимся ещё одним шаблоном проектирования. Самый известный (с моей точки зрения) пример использования — Lazy-инициализация бинов в Hibernate.

2) Создание Proxy в простейшем случае делается с помощью классов Proxy / InvokationHandler, которые позволяют создать прокси для любого набора интерфейсов. Однако часто приходится оборачивать не интерфейсы (EJB 2.x — это были бы Remote/Local интерфейсы), а классы (EJB 3.x). В этом случае используются фреймворки вроде CGLIB / ASM / Javaassist для реализации шаблона Proxy через наследование, т.е. через создание дочернего класса и оборачивания всех super-вызовов нужным кодом.

Это всё, конечно, в случае необходимости оборачивания Proxy в runtime, когда класс на момент компиляции не знает, что придётся оборачивать. И хотя при этом страдает производительность, данный подход имеет плюсы и в случае статической компиляции — если мы добавим новый метод в исходный объект, в «динамических» прокси нам менять ничего не нужно, а вот «статические» придётся дописывать.

3) Proxy бывают и нелокальные, например, предназначенные для вызова методов объекта в удалённой JVM. Обычно реализуются через Proxy / InvokationHandler, так как у объекта есть RemoteInterface.
так вот почему проги на яве так тормозят…
Частенько юзаю в MVC эту концепцию, давая view'у вместо исходной модели proxy модель.
> Необходимо контролировать доступ к объекту, не изменяя при этом, поведение клиента.

Вторая запятая явно лишняя
Да и вообще в тексте куча лишних запятых. Кошмар!!!
Да где же? Можно конкретнее?
Вторую запятую убрал :)
Мотивацией для этого служит ряд приобретаемых преимуществ.


Перевод очень «топорный».

Идея паттерна «Заместитель» заключается в предоставлении клиенту другого объекта (заместителя), взамен объекту с контролируемым доступом


Да и покрытие темы поверхностно.

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

П.С.: Интереса ради глянул как написано в русской вике:
Поскольку интерфейс «Реального Субъекта» идентичен интерфейсу «Субъекта», так, что «Заместителя» можно подставить вместо «Реального Субъекта», контролирует доступ к «Реальному Субъекту», может отвечать за создание или удаление «Реального Субъекта».


тоже жесть =)
Перевод очень «топорный».

Это не перевод :) Это написано от себя лично, естественно после прочтения GoF, поэтому общие нотки прослеживаются.

Да и покрытие темы поверхностно.

Мне кажется, что моя интерпретация более понятна, чем на википедии. Хотя судить Вам.
Only those users with full accounts are able to leave comments. Log in, please.