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.
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 модель.
> Необходимо контролировать доступ к объекту, не изменяя при этом, поведение клиента.
Вторая запятая явно лишняя
Вторая запятая явно лишняя
Мотивацией для этого служит ряд приобретаемых преимуществ.
Перевод очень «топорный».
Идея паттерна «Заместитель» заключается в предоставлении клиенту другого объекта (заместителя), взамен объекту с контролируемым доступом
Да и покрытие темы поверхностно.
Вообще мне как-то приходила в голову идея, похожая на прокси шаблон для сокрытия некоторых методов класса и частичного ограничения на параметры других методов (админ может менять редактировать сообщение, пользователь не может). Сейчас узнал, что это называется защищающий прокси =)
П.С.: Интереса ради глянул как написано в русской вике:
Поскольку интерфейс «Реального Субъекта» идентичен интерфейсу «Субъекта», так, что «Заместителя» можно подставить вместо «Реального Субъекта», контролирует доступ к «Реальному Субъекту», может отвечать за создание или удаление «Реального Субъекта».
тоже жесть =)
Sign up to leave a comment.
Паттерн проектирования «Заместитель» / «Proxy»