Шаблон проектирования прокси: недостатки

Я просматривал одну из статей о шаблоне прокси.

Прочитайте комментарии после объяснения

В этой статье упоминается несколько недостатков шаблонов прокси, но я не могу понять:

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

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

Пожалуйста, объясните.

3) если прокси используется для представления удаленного ресурса в локальном процессе, это может скрыть тот факт, что задействована удаленная связь. Как мы знаем, удаленный вызов полностью отличается от локального вызова, и наши программы не должны относиться к нему так, как будто это одно и то же. Лучше, если прокси каким-то образом заявит, что это прокси для удаленного ресурса, а не для локального ресурса. Тогда клиенты смогут выбирать только локальные ресурсы или изменять свое поведение при использовании удаленного ресурса.

Не могли бы вы помочь мне понять три пункта выше, связанные с недостатками прокси-сервера?


java design-patterns proxy-pattern
person Sunny Gupta    schedule 18.08.2013    source источник

Ответы (1)


arrow_upward
1
arrow_downward

Получается 3 разных вопроса. Отвечу на третий. Вам лучше изменить свой вопрос на один и задать каждый из двух других в отдельном вопросе.

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

Возьмите этот пример, например:

if (account.getBalance() > 0 && account.getBalance() < MAX) {
    transferAmount(account.getBalance() / 2);
}

Теперь представьте, что account — это прокси для удаленного объекта. Каждый раз, когда вызывается getBalance(), выполняется удаленный сетевой вызов, который потенциально может привести к исключению или даже каждый раз возвращать другое значение, что делает этот простой фрагмент кода крайне неэффективным.

person JB Nizet    schedule 18.08.2013
comment
Я полагаю, что это объяснение более или менее охватывает и первый случай. Можно сказать, что прозрачное выполнение удаленных вызовов можно считать случаем, когда происходит волшебство. - person c.s.; 19.08.2013